什么是RESTful编程？

小开

REST是网络的底层架构原则。网络的神奇之处在于客户端（浏览器）和服务器可以以复杂的方式交互，而客户端事先不知道服务器及其托管的资源。关键的约束是服务器和客户端必须就使用的媒体达成一致，在网络的情况下是超文本标记语言。

遵循REST原则的API不需要客户端了解API的结构。相反，服务器需要提供客户端与服务交互所需的任何信息。超文本标记语言就是一个例子：服务器指定资源的位置和所需的字段。浏览器事先不知道在哪里提交信息，也不知道要提交什么信息。这两种形式的信息都完全由服务器提供。（这个原则被称为HATEOAS：超媒体作为应用程序状态的引擎。）

那么，这如何适用于HTTP，以及如何在实践中实现呢？ HTTP是围绕动词和资源的。主流使用的两个动词是GET和POST，我想每个人都会认识。但是，HTTP标准定义了其他几个动词，例如PUT和DELETE。然后根据服务器提供的说明，这些动词应用于资源。

例如，假设我们有一个由Web服务管理的用户数据库。我们的服务使用基于JSON的自定义超媒体，我们为其分配了mimetypeapplication/json+userdb（也可能有application/xml+userdb和application/whatever+userdb-可能支持许多媒体类型）。客户端和服务器都被编程为理解这种格式，但它们对彼此一无所知。正如Roy Fielding指出的：

REST API应该将几乎所有的描述性工作都花在定义用于表示资源和驱动的媒体类型应用程序状态，或定义扩展关系名称和/或对现有标准媒体类型启用超文本的标记。

对基本资源/的请求可能会返回如下内容：

请求

GET /Accept: application/json+userdb

响应

200 OKContent-Type: application/json+userdb
{"version": "1.0","links": [{"href": "/user","rel": "list","method": "GET"},{"href": "/user","rel": "create","method": "POST"}]}

我们从媒体的描述中知道，我们可以从称为“链接”的部分中找到相关资源的信息。这被称为超媒体控制。在这种情况下，我们可以从这样的部分中得知，我们可以通过再次请求/user来找到用户列表：

请求

GET /userAccept: application/json+userdb

响应

200 OKContent-Type: application/json+userdb
{"users": [{"id": 1,"name": "Emil","country: "Sweden","links": [{"href": "/user/1","rel": "self","method": "GET"},{"href": "/user/1","rel": "edit","method": "PUT"},{"href": "/user/1","rel": "delete","method": "DELETE"}]},{"id": 2,"name": "Adam","country: "Scotland","links": [{"href": "/user/2","rel": "self","method": "GET"},{"href": "/user/2","rel": "edit","method": "PUT"},{"href": "/user/2","rel": "delete","method": "DELETE"}]}],"links": [{"href": "/user","rel": "create","method": "POST"}]}

我们可以从这个响应中看出很多。例如，我们现在知道我们可以通过POSTing到/user创建一个新用户：

请求

POST /userAccept: application/json+userdbContent-Type: application/json+userdb
{"name": "Karl","country": "Austria"}

响应

201 CreatedContent-Type: application/json+userdb
{"user": {"id": 3,"name": "Karl","country": "Austria","links": [{"href": "/user/3","rel": "self","method": "GET"},{"href": "/user/3","rel": "edit","method": "PUT"},{"href": "/user/3","rel": "delete","method": "DELETE"}]},"links": {"href": "/user","rel": "list","method": "GET"}}

我们还知道我们可以更改存量数据：

请求

PUT /user/1Accept: application/json+userdbContent-Type: application/json+userdb
{"name": "Emil","country": "Bhutan"}

响应

200 OKContent-Type: application/json+userdb
{"user": {"id": 1,"name": "Emil","country": "Bhutan","links": [{"href": "/user/1","rel": "self","method": "GET"},{"href": "/user/1","rel": "edit","method": "PUT"},{"href": "/user/1","rel": "delete","method": "DELETE"}]},"links": {"href": "/user","rel": "list","method": "GET"}}

请注意，我们使用不同的HTTP动词（GET、PUT、POST、DELETE等）来操作这些资源，我们对客户端的唯一假设是我们的媒体定义。

进一步阅读：

（这个答案因为没有抓住重点而受到相当多的批评。在大多数情况下，这是一个公平的批评。我最初描述的更符合几年前我第一次写这篇文章时REST的实现方式，而不是它的真正含义。我修改了答案，以更好地代表真正的含义。）

小开

它是您的系统架构符合Roy Fielding在他的论文中提出的REST样式的编程。由于这是描述Web的架构风格（或多或少），很多人对它感兴趣。

奖励答案：不，除非你正在学习软件架构作为学术或设计Web服务，否则真的没有理由听过这个术语。

小开

REST使用各种HTTP方法（主要是GET/PUT/DELETE）来操作数据。

而不是使用特定的URL来删除方法（例如/user/123/delete），您可以向/user/[id] URL发送DELETE请求，以编辑用户，检索您向/user/[id]发送GET请求的用户的信息

例如，相反，一组URL可能看起来像以下一些…

GET /delete_user.x?id=123GET /user/deleteGET /new_user.xGET /user/newGET /user?id=1GET /user/id/1

您使用HTTP“动词”并具有…

GET /user/2DELETE /user/2PUT /user

小开

我看到一堆答案说将用户123的所有内容放在资源“/user/123”是RESTful。

创造这个术语的Roy Fielding说REST API必须是超文本驱动的。特别是，“REST API不得定义固定的资源名称或层次结构”。

因此，如果您的“/user/123”路径是在客户端上硬编码的，那么它并不是真正的RESTful。很好地使用了HTTP，也许，也许不是。但不是RESTful。它必须来自超文本。

小开

RESTful编程是关于：

由持久标识符标识的资源：URI是当今无处不在的标识符选择
使用一组常见的动词操纵资源：HTTP方法是常见的情况——古老的Create、Retrieve、Update、Delete变成了POST、GET、PUT和DELETE。但REST不仅限于HTTP，它只是现在最常用的传输。
检索到的资源的实际表示取决于请求而不是标识符：使用接受标头来控制是否需要XML、HTTP甚至是表示资源的Java对象
维护对象中的状态并在表示中表示状态
在资源的表示中表示资源之间的关系：对象之间的链接直接嵌入在表示中
资源表示描述了如何使用表示以及在什么情况下应该以一致的方式丢弃/重新获取：HTTP Cache-Control标头的使用

就REST的后果和整体有效性而言，最后一个可能是最重要的。总的来说，大多数关于RESTful的讨论似乎都集中在HTTP及其在浏览器中的使用以及其他方面。我知道R. Fielding在描述导致HTTP的架构和决策时创造了这个术语。他的论文更多的是关于资源的架构和缓存能力，而不是HTTP。

如果你真的对什么是RESTful架构以及它为什么工作感兴趣，请多读几次他的论文并阅读整件事而不仅仅是第5章！接下来看看为什么DNS工作。阅读有关DNS的分层组织以及引用是如何工作的。然后阅读并考虑DNS缓存是如何工作的。最后，阅读HTTP规范（特别是RFC2616和RFC3040）并考虑缓存是如何以及为什么以这种方式工作的。最终，它会点击。对我来说，最后的启示是当我看到DNS和HTTP之间的相似性时。之后，理解为什么SOA和消息传递接口是可扩展的开始点击。

我认为理解RESTful和没有分享架构的架构重要性和性能影响的最重要技巧是避免被技术和实现细节所困扰。专注于谁拥有资源，谁负责创建/维护它们等。然后考虑表示、协议和技术。

小开

如果我没有直接回答这个问题，我很抱歉，但是通过更详细的例子更容易理解这一切。由于所有的抽象和术语，字段不容易理解。

这里有一个相当好的例子：

解释REST和超文本： Spam-E垃圾邮件清理机器人

更好的是，这里有一个简单的例子的清晰解释（PowerPoint更全面，但你可以在html版本中获得大部分内容）：

http://www.xfront.com/REST.ppt或http://www.xfront.com/REST.html

阅读示例后，我明白了为什么Ken说REST是超文本驱动的。但我不确定他是否正确，因为 /user/123是指向资源的URI，我不清楚它是否是unRESTful，仅仅因为客户端知道它“带外”。

该xFront文档解释了REST和SOAP之间的区别，这也非常有帮助。当Fielding说“这是RPC。它尖叫着RPC。”时，很明显RPC不是RESTful，因此查看其确切原因很有用。（SOAP是RPC的一种类型。）

小开

这就是它可能看起来的样子。

创建一个具有三个属性的用户：

POST /userfname=John&lname=Doe&age=25

服务器响应：

200 OKLocation: /user/123

将来，您可以检索用户信息：

GET /user/123

服务器响应：

200 OK<fname>John</fname><lname>Doe</lname><age>25</age>

修改记录（lname和age保持不变）：

PATCH /user/123fname=Johnny

要更新记录（因此lname和age将为NULL）：

PUT /user/123fname=Johnny

小开

一本关于REST的好书是REST实践。

必须读取具象状态转移（REST）和REST API必须是超文本驱动的

有关什么是RESTful服务的解释，请参阅Martin Fowler文章理查森成熟度模型（RMM）。

理查森成熟度模型

要成为RESTful，服务需要满足超媒体作为应用程序状态的引擎。（HATEOAS），也就是说，它需要在RMM中达到级别3，详细信息为阅读这篇文章或来自qcon谈话的幻灯片。

HATEOAS约束是一个缩写作为超媒体的引擎这一原则是REST之间的关键区别和大多数其他形式的客户端服务器系统。

…

RESTful应用程序的客户端需要只知道一个固定的URL访问它。所有未来的行动应该是动态发现从中包含的超媒体链接表示的资源从该URL返回。标准化媒体类型也期望被任何可能使用RESTful API的客户端。（来自维基百科，自由的百科全书）

Web框架的REST Litmus测试是一个类似的Web框架成熟度测试。

接近纯粹的休息：学会爱HATEOAS是一个很好的链接集合。

公共云的REST与SOAP讨论了REST使用的当前级别。

REST和版本控制讨论了可扩展性、版本控制、可进化性等。可修改性

小开

如果我不得不将关于REST的原始论文缩减为三个简短的句子，我认为以下内容抓住了它的本质：

资源通过URL请求。
协议仅限于您可以使用URL进行通信的内容。
元数据作为名称-值对（发布数据和查询字符串参数）传递。

在那之后，很容易陷入关于适应、编码约定和最佳实践的争论。

有趣的是，论文中没有提到HTTP POST、GET、DELETE或PUT操作。这一定是某人后来对“统一接口”的“最佳实践”的解释。

说到Web服务，我们似乎需要某种方式来区分基于WSDL和SOAP的架构，这会增加相当大的开销，并且可以说会给接口增加很多不必要的复杂性。它们还需要额外的框架和开发工具来实现。我不确定REST是否是区分常识接口和过度设计的接口（如WSDL和SOAP）的最佳术语。但我们需要一些东西。

小开

REST是一种编写分布式应用程序的架构模式和风格。它不是狭义的编程风格。

说您使用REST风格类似于说您以特定风格建造了房屋：例如都铎或维多利亚风格。作为软件风格的REST和作为家庭风格的都铎或维多利亚风格都可以通过构成它们的质量和约束来定义。例如，REST必须有客户端服务器分离，其中消息是自我描述的。都铎风格的房屋有重叠的山墙和屋顶，它们与前向山墙陡峭地倾斜。您可以阅读Roy的论文以了解有关构成REST的约束和质量的更多信息。

与家庭风格不同，REST在持续和实际应用方面遇到了困难。这可能是故意的。将其实际实现留给设计师。因此，只要您满足您正在创建REST系统的论文中规定的约束，您就可以自由地做您想做的事情。

奖金：

整个Web都基于REST（或者REST基于Web）。因此，作为Web开发人员，您可能希望了解这一点，尽管没有必要编写好的Web应用程序。

小开

休息的要点是，如果我们同意使用通用语言进行基本操作（超文本传输协议动词），则可以配置基础设施以理解它们并正确优化它们，例如，通过使用缓存标头来实现各级缓存。

使用正确实现的restful GET操作，无论信息来自服务器的DB、服务器的memache、CDN、代理的缓存、浏览器的缓存还是浏览器的本地存储，都应该无关紧要。可以使用快速、最容易获得的最新源。

说Rest只是从使用带有动作参数的GET请求到使用可用的超文本传输协议动词的语法改变，让它看起来没有任何好处，纯粹是摆架子。关键是使用一种链上每个部分都能理解和优化的语言。如果你的GET操作有副作用的动作，你必须跳过所有的HTTP缓存，否则最终会得到不一致的结果。

小开

什么是休息？

REST代表具象状态转移。（有时拼写为“ReST”。）它依赖于无状态、客户端-服务器、可缓存通信协议——几乎在所有情况下，HTTP使用协议。

REST是一种用于设计网络应用程序的架构风格。这个想法是，而不是使用像CORBA这样的复杂机制，RPC或SOAP用于机器之间的连接，使用简单的HTTP进行连接机器之间的调用。

在许多方面，可以查看基于HTTP的万维网本身作为基于REST的架构。RESTful应用程序使用HTTP请求发布数据（创建和/或更新），读取数据（例如，进行查询），并删除数据。因此，REST对所有四个CRUD都使用HTTP（创建/读取/更新/删除）操作。

REST是RPC（Remote）等机制的轻量级替代方案过程调用）和Web服务（SOAP、WSDL等）。稍后，我们将看看REST有多简单。

尽管很简单，REST功能齐全；基本上有您可以在Web服务中做任何不能使用RESTful完成的事情架构。REST不是“标准”。永远不会有W3C例如，REST的推荐。虽然有REST编程框架，使用REST非常简单，您可以通常使用诸如以下语言的标准库功能“滚动自己的”Perl、Java或C#。

当我试图找到休息的简单真正含义时，我发现了最好的参考之一。

http://rest.elkstein.org/

小开

我想说RESTful编程是关于创建遵循REST架构风格的系统（API）。

我找到了M. Elkstein博士关于REST的精彩、简短且易于理解的教程，并引用了大部分可以回答您问题的基本部分：

学习REST：教程

REST是用于设计网络应用程序的建筑风格。这个想法是，而不是使用像CORBA这样的复杂机制，RPC或SOAP用于机器之间的连接，使用简单的HTTP进行连接机器之间的调用。

在许多方面，基于HTTP的万维网本身可以被视为基于REST的架构。

RESTful应用程序使用HTTP请求发布数据（创建和/或更新）、读取数据（例如，进行查询）和删除数据。因此，REST所有四个CRUD（创建/读取/更新/删除）操作都使用HTTP。

我不认为你应该因为没有在Stack Overflow之外听到REST而感到愚蠢……，我也会遇到同样的情况！；回答为什么REST现在变得越来越大上的另一个SO问题可以缓解一些感觉。

小开

REST是一种分布式系统（如WWW）软件架构风格，可以想象它是一个精心设计的Web应用程序规则：一组Internet Web页面（一个虚拟状态机），通过点击其中的超链接链接（状态转换），结果是下一个Web页面（这意味着应用程序的下一个状态）。

REST描述的网络系统由三部分组成：

数据元素（资源、资源标识符、表示）
连接器（客户端、服务器、缓存、解析器、隧道）
组件（源服务器、网关、代理、用户代理）

REST严格满足以下条件：

应用程序功能的状态被分割为资源
每个资源用作超链接定位语法（即，在WWW URI中）
所有资源在客户端与资源转换状态之间共享一个统一的接口，包括：
1. 一组有限的定义良好的操作（即在HTTP GET/POST/PUT/DELETE中）
2. 一组有限的内容格式内容类型，其中可能包括执行代码（即，在WWW Javascript中）

小开

什么是休息？

用官方的话说，REST是一种基于当前“Web”基础的某些原则构建的架构风格。有5个基本的Web基础可以用来创建REST服务。

原则2：每个资源都由唯一标识符（URI）标识
原则3：使用简单而统一的界面
原则4：沟通是通过表象完成的
原则5：无状态

小开

答案很简单，Roy Fielding写了一个论文。]1在那篇论文中，他定义了REST原则。如果一个应用程序满足所有这些原则，那么这就是一个REST应用程序。

术语RESTful的创建是因为ppl通过将其非REST应用程序调用为REST来耗尽REST一词。之后，术语RESTful也用完了。现在我们谈论的是Web API和Hypermedia API，因为大多数所谓的REST应用程序都没有满足统一接口约束的HATEOAS部分。

REST约束如下：

客户端-服务器架构

所以它不适用于例如PUB/SUB套接字，它基于REQ/REP。
无状态通信

所以服务器不维护客户端的状态。这意味着您不能使用服务器端会话存储，您必须对每个请求进行身份验证。您的客户端可能通过加密连接发送基本的身份验证标头。（对于大型应用程序来说，很难维护多个会话。）
使用缓存，如果可以的话

所以你不必一次又一次地提供相同的请求。
统一接口作为客户端和服务器之间的公共契约

客户端和服务器之间的契约不是由服务器维护的。换句话说，客户端必须与服务的实现解耦。您可以通过使用标准解决方案来达到这种状态，例如IRI（URI）标准来识别资源，HTTP标准来交换消息，标准MIME类型来描述正文序列化格式，元数据（可能是RDF词汇、微格式等）来描述消息正文不同部分的语义学。要将IRI结构与客户端解耦，您必须以超媒体格式（超文本标记语言、JSON-LD、HAL等）向客户端发送超链接。因此，客户端可以使用分配给超链接的元数据（可能是链接关系，RDF词汇表）通过适当的状态转换来导航应用程序的状态机，以实现其当前目标。

例如，当客户端想向网店发送订单时，它必须检查网店发送的响应中的超链接。通过检查它找到的链接，它找到了http://schema.org/OrderAction描述的链接。客户端知道schema.org词汇表，所以它理解通过激活这个超链接它将发送订单。所以它激活超链接并发送一个带有正确正文的POST https://example.com/api/v1/order消息。之后，服务处理消息并以具有正确HTTP状态标头的结果响应，例如201 - created成功。要使用详细的元数据注释消息，标准解决方案是使用RDF格式，例如JSON-LD和REST词汇，例如九头蛇和领域特定的词汇，如schema.org或任何其他关联数据词表，如果需要，可能还有自定义应用程序特定的词汇。现在这并不容易，这就是为什么大多数ppl使用HAL和其他简单格式，通常只提供REST词汇，但没有链接数据支持。
构建分层系统以提高可扩展性

REST系统由分层组成。每一层都包含使用下一层组件服务的组件。因此您可以轻松添加新层和组件。

例如，有一个包含客户端的客户端层，下面有一个包含单个服务的服务层。现在你可以在它们之间添加客户端缓存。之后，你可以添加另一个服务实例和负载均衡器，依此类推…客户端代码和服务代码不会改变。
扩展客户端功能的按需代码

此约束是可选的。例如，您可以将特定媒体类型的解析器发送到客户端，依此类推……为此，您可能需要在客户端中使用标准插件加载器系统，或者您的客户端将耦合到插件加载器解决方案。

REST约束导致了一个高度可扩展的系统，在这个系统中，客户端与服务的实现解耦。因此，客户端可以像网络上的浏览器一样可重用、通用。客户端和服务共享相同的标准和词汇，因此尽管客户端不知道服务的实现细节，但它们可以相互理解。这使得创建自动化客户端成为可能，这些客户端可以找到和利用REST服务来实现他们的目标。从长远来看，这些客户端可以像人类一样，在任务中相互通信并相互信任。如果我们为这些客户端添加学习模式，那么结果将是一个或多个人工智能使用机器网络而不是单个服务器园区。所以最终伯纳斯·李的梦想：语义网和人工智能将成为现实。所以在2030年，我们最终会被天网终结。在那之前…；-）

小开

RESTful（具象状态转移）API编程是通过以下5个基本软件建筑风格原则以任何编程语言编写Web应用程序：

资源（数据、信息）。
唯一全局标识符（所有资源都是由URI标识的唯一资源）。
统一接口-使用简单和标准的接口（HTTP）。
表示-所有通信都是通过表示完成的（例如xml/JSON）
无国籍（每个请求都是完全隔离的，更容易缓存和负载平衡）

换句话说，你正在通过HTTP编写简单的点对点网络应用程序，该应用程序使用GET、POST、PUT或DELETE等动词，通过实现RESTful架构，该架构建议每个“资源”公开的接口标准化。以简单有效的方式使用网络的当前功能（高度成功、经过验证和分布式的架构）并不是什么。它是更复杂机制（如SOAP、CORBA和RPC）的替代方案。

RESTful编程符合Web架构设计，如果实施得当，它允许您充分利用可扩展的Web基础架构。

小开

我认为RESTful的重点是把状态分离成一个更高的层次，而使用Internet（协议）作为无状态传输层。大多数其他方法都会混淆事情。

面对互联网时代编程的根本变化，这是最实用的方法。关于根本的变化，Erik Mayjer在show：http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197上有讨论。他总结为五个效应，并给出了一个解决方案，他把这个解决方案设计成一种编程语言。也可以在平台层或者系统层实现，不分语言。restful可以说是目前实践中非常成功的解决方案之一。

使用restful风格，你可以在不可靠的互联网上获取和操作应用程序的状态。如果它在当前操作中失败以获得正确的当前状态，它需要零验证主体来帮助应用程序继续。如果它无法操纵状态，它通常使用多阶段确认来保持正确。从这个意义上说，rest本身并不是一个完整的解决方案，它需要Web应用程序堆栈的其他部分的函数来支持它的工作。

鉴于这种观点，rest样式并不真正与互联网或Web应用程序相关。它是许多编程情况的基本解决方案。它也不简单，它只是让界面变得非常简单，并很好地应对其他技术。

我的2c

编辑：两个更重要的方面：

无国籍状态具有误导性。它是关于RESTful API，而不是应用程序或系统。系统需要有状态。RESTful设计是关于基于无状态API设计有状态系统。一些来自其他QA的评论：
- REST，对资源表示进行操作，每个表示都由URL标识。这些通常不是数据对象，而是复杂对象抽象。
- REST代表“代表性状态转移”，这意味着它完全是关于通信和修改系统中某些资源的该州。
幂等：REST中一个经常被忽视的部分是大多数动词的幂等性。这导致了健壮的系统和更少的语义学精确解释的相互依赖

小开

REST代表具象状态转移。

它依赖于无状态、客户端-服务器、可缓存的通信协议——几乎在所有情况下，都使用HTTP协议。

REST通常用于移动应用程序、社交网络网站、混搭工具和自动化业务流程。REST风格强调通过有限数量的操作（动词）来增强客户端和服务之间的交互。通过将资源（名词）分配给它们自己唯一的通用资源指标（URI）来提供灵活性。

关于休息的介绍

小开

说话不仅仅是交换信息。协议的设计实际上是为了不需要对话。每一方都知道他们的特定工作是什么，因为它在协议中指定了。协议允许纯粹的信息交换，代价是可能的行动发生任何变化。另一方面，对话允许一方问另一方可以采取什么进一步的行动。他们甚至可以问两次同一个问题，得到两个不同的答案，因为另一方的国家可能在此期间发生了变化。说话是RESTful架构。菲尔丁的论文指定了一个架构，如果一个人想让机器说话到另一个，而不是简单的沟通。

小开

最佳答案

一个名为REST（具象状态转移）的建筑风格主张Web应用程序应该像最初设想一样使用HTTP。查找应该使用#0请求。#1、#2、#3请求应该分别用于突变、PUT0和PUT1。
REST支持者倾向于支持URL，例如
http://myserver.com/catalog/item/1729
但是REST架构不需要这些“漂亮的URL”。带有参数的GET请求
http://myserver.com/catalog?item=1729
每一点都像RESTful。
请记住，GET请求不应该用于更新信息。例如，用于将项目添加到购物车的GET请求
http://myserver.com/addToCart?cart=314159&item=1729
GET请求应该是幂等。也就是说，发出两次请求应该和发出一次没有什么不同。这就是请求可以缓存的原因。“添加到购物车”请求不是幂等的-发出两次会将该项目的两个副本添加到购物车。POST请求在这种情况下显然是合适的。因此，即使是RESTful Web应用程序也需要它的POST请求份额。
这是来自David M. Geary的优秀书籍核心JavaServer面临。

小开

REST===HTTP类比是不正确的，除非您不强调它“必须”是HATEOAS驱动的事实。

罗伊自己清除了它这里。

输入REST API时，除了初始URI（书签）和一组适合目标受众（即预期可能使用该API的任何客户端都能理解）的标准化媒体类型之外，不应有任何先验知识。从那时起，所有应用程序状态转换必须由客户端对服务器提供的选择的选择驱动，这些选择存在于接收到的表示中，或由用户对这些表示的操作隐含。转换可能由客户端对媒体类型和资源通信机制的知识来确定（或限制），这两者都可以动态改进（例如按需代码）。

[这里的失败意味着带外信息正在推动交互而不是超文本。

小开

什么是API测试

API测试是利用编程向API发送调用并获得产量。它将被测段视为一个黑盒。API测试的目的是确认其协调进入应用程序之前的部分的正确执行和错误处理。

RESTAPI

REST：具象状态转移。

它是测试人员执行请求和接收响应的功能安排。在REST API中，交互是通过HTTP协议进行的。
REST还允许计算机之间通过网络进行通信。
对于发送和接收消息，它涉及使用HTTP方法，并且与Web服务不同，它不需要严格的消息定义。
REST消息通常以XML或JavaScript对象表示法（JSON）的形式接受表单。

4种常用的API方法：-

GET：它提供对资源的只读访问。
POST：-它用于创建或更新新资源。
PUT：用于更新或替换现有资源或创建新资源。
DELETE：用于删除资源。

手动测试API的步骤：-

要手动使用API，我们可以使用基于浏览器的REST API插件。

安装POSTMAN（Chrome）/REST（Firefox）插件
输入API URL
选择REST方法
选择内容-标题
输入请求JSON（POST）
点击发送
它将返回输出响应

自动化REST API的步骤

小开

没有“RESTful编程”本身这样的概念。它最好被称为RESTful范式，甚至更好的RESTful架构。它不是一种编程语言。它是一种范式。

来自wikipedia：

在计算中，代表性状态转移（REST）是一种用于Web开发的架构风格。

小开

老问题，新的回答方式。关于这个概念有很多误解。我总是试着记住：

结构化URL和Http方法/动词不是宁静的编程。
JSON不是RESTful编程
RESTful编程不适用于API

我将RESTful编程定义为

如果应用程序以客户端理解的媒体类型提供资源（数据+状态转换控件的组合），则应用程序是RESTful

要成为一个安静的程序员，您必须尝试构建允许参与者做事的应用程序。不仅仅是公开数据库。

状态转换控件只有在客户端和服务器就资源的媒体类型表示达成一致时才有意义。否则就无法知道什么是控件，什么不是控件以及如何执行控件。IE如果浏览器不知道html中的<form>标签，那么您就没有任何东西可以提交到浏览器中的转换状态。

我不是想自我推销，但我在我的演讲http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html中深入阐述了这些想法。

我演讲的摘录是关于经常提到的理查森成熟度模型，我不相信关卡，你要么是RESTful（3级），要么不是，但我想说的是每个关卡在你通往RESTful的路上为你做了什么

小开

这是一个非常长的“讨论”，但至少可以说相当混乱。

海事组织：

1）没有宁静的编程，没有一个大的联合和大量的啤酒：）

2）具象状态传输（REST）是罗伊·菲尔丁的论文中指定的架构样式。它有许多约束。如果您的服务/客户端尊重这些约束，那么它就是RESTful。就是它。

您可以将约束（显着）总结为：

无状态通信
尊重HTTP规范（如果使用HTTP）
清楚地传达传输的内容格式
使用超媒体作为应用程序状态的引擎

还有另一个非常好的帖子很好地解释了事情。

很多答案复制/粘贴了有效的信息，混合了它并增加了一些混乱。人们在这里谈论级别，关于RESTFul URI（没有这样的事情！），应用HTTP方法GET、POST、PUT… REST不是关于那个或不仅仅是关于那个。

例如链接——有一个漂亮的API很好，但最终客户端/服务器并不真正关心你获得/发送的链接，重要的是内容。

最后只要内容格式已知，任何RESTful客户端都应该能够使用任何RESTful服务。

小开

这是我对REST的基本概述。我试图展示RESTful架构中每个组件背后的思想，以便更直观地理解这个概念。希望这有助于一些人揭开REST的神秘面纱！
REST（具象状态传输）是一种设计架构，它概述了网络资源（即共享信息的节点）是如何设计和寻址的。一般来说，RESTful架构使客户端（请求机器）和服务器（响应机器）可以请求读取、写入和更新数据，而客户端无需知道服务器如何操作，服务器可以在不需要了解客户端任何信息的情况下将数据传递回来。好吧，很酷……但是我们在实践中如何做到这一点？
最明显的要求是需要有某种通用语言，以便服务器可以告诉客户端它试图对请求做什么，并让服务器做出响应。
但是要找到任何给定的资源，然后告诉客户端该资源的位置，需要有一种指向资源的通用方式。这就是通用资源标识符（URI）的用武之地；它们基本上是查找资源的唯一地址。
虽然上述满足了我们想要的基本需求，但我们还希望有一个支持大流量的架构，因为任何给定的服务器通常都处理来自多个客户端的响应。因此，我们不想让服务器记住以前请求的信息，从而压倒服务器。
因此，我们限制客户端和服务器之间的每个请求-响应对都是独立的，这意味着服务器不必记住任何关于以前的请求（客户端-服务器交互的以前状态）来响应新请求。这意味着我们希望我们的交互是无状态的。
为了进一步缓解重做最近已经为给定客户端完成的计算对我们服务器的压力，REST还允许缓存。基本上，缓存意味着获取提供给客户端的初始响应的快照。如果客户端再次发出相同的请求，服务器可以向客户端提供快照，而不是重做创建初始响应所需的所有计算。但是，由于它是一个快照，如果快照没有过期——服务器提前设置了过期时间——并且响应自初始缓存以来一直在更新（即请求将给出与缓存响应不同的答案），客户端将看不到更新，直到缓存过期（或缓存被清除）并再次从头开始呈现响应。
关于RESTful架构，你经常在这里看到的最后一件事是它们是分层的。我们实际上已经在我们关于客户端和服务器之间交互的讨论中隐含地讨论了这个要求。基本上，这意味着我们系统中的每一层只与相邻层交互。因此，在我们的讨论中，客户端层与我们的服务器层交互（反之亦然），但可能有其他服务器层帮助主服务器处理客户端不直接通信的请求。相反，服务器会根据需要传递请求。
现在，如果这一切听起来很熟悉，那就太好了。超文本传输协议（HTTP）定义了通过万维网的通信协议，是RESTful架构抽象概念的实现（或者如果你像我一样是OOP狂热分子，则是抽象REST类的实现）。在REST的这个实现中，客户端和服务器通过GET、POST、PUT、DELETE等进行交互。这些是通用语言的一部分，资源可以使用URL指向。

小开

这在任何地方都很少被提及，但理查森成熟度模型是实际判断RESTful是一个人的API的最佳方法之一。更多关于它的信息在这里：

理查森的成熟度模型

小开

REST定义了6个架构约束，这些约束使任何Web服务成为RESTful API。

统一接口
客户端-服务器端
无国籍
可缓存
分层系统
按需代码（可选）

https://restfulapi.net/rest-architectural-constraints/

小开

编辑

在这里阅读README，我希望你能真正得到休息。

https://github.com/lukepuplett/surfdude-csharp/blob/master/README.md

--

那些给出链接资源示例的答案很棒，但只是图片的一半。

想象你在设计一个网站。你写了一个故事，

我想能够搜索一个地址的邮政编码以便我可以选择一个送货地址

然后，您将构建网站以带领用户进行该旅程，并尝试在工作流程中将页面链接在一起。

将他们带到地址查找的网站设计，然后让他们将地址复制到剪贴板中，然后返回到送货地址表单将不是很有用。

REST API使用我们在Web上认为理所当然的模式进行机器-机器交互。

对邮政编码功能的搜索不应该是base/addresses/{postcode}并返回集合，即使每个地址链接到完整地址和一些编辑链接，因为这是一个死胡同；API消费者需要猜测如何使用该地址。

相反，该功能的动机应该内置于其使用的流程中，以便旅程在开始时结束：

1 GET /orders/123/shipping 200 OK { Current shipping details + link to parent + link to address picker } 2 -> GET /orders/123/shipping/addresspicker 200 OK { Link and form for searching for a postcode } 3 -> GET /orders/123/shipping/addresspicker?postcode=tn11tl 200 OK { List of addresses each with link to pick it } 4 -> POST /orders/123/shipping/addresspicker?postcode=tn11tl&pickNo=3 200 OK { Current shipping details + link to parent + link to address picker }

这是一个用户旅程，最后您可以看到流程对订单的影响。

HTTP请求/响应严格来说不是REST的一部分，但我认为没有人见过非HTTP REST应用程序。

现在这些URL可以是任何一组字符，它们只是标识符，我把它们做得很漂亮，因为它们对人们有意义。机器会使用rel来计算它们做什么，而不依赖于可读的href。

小开

我想说的是，理解REST的一个重要构建块在于端点或映射，例如/customers/{id}/balance。

你可以将这样的端点想象成从网站（前端）到数据库/服务器（后端）的连接管道。使用它们，前端可以执行后端操作，这些操作在应用程序中任何REST映射的相应方法中定义。

小开

REST API是一种遵守REST体系结构约束的API实现。它充当接口。客户端和服务器之间的通信通过HTTP进行。REST API利用HTTP方法来建立客户端和服务器之间的通信。REST还使服务器能够缓存响应，从而提高应用程序的性能。客户端和服务器之间的通信是一个无状态过程。我的意思是，客户端和服务器之间的每一次通信都像一次新的通信。

没有从以前的通信中携带的信息或内存。因此，每次客户端与后端交互时，它都必须将鉴别信息发送给它。这使后端能够确定客户端是否有权访问数据。

通过REST API的实现，客户端获得与之通信的后端端点。这完全解耦了后端和客户端代码。

小开

这个答案是绝对的初学者，让我们了解当今最常用的API架构。

要了解RESTful编程或RESTful API。首先，您必须了解API是什么，在非常高级的API上代表应用程序编程接口，它基本上是一个软件，可以被另一个软件使用，以便允许应用程序相互通信。

全球使用最广泛的API类型是Web API，而当请求进入时，它会将数据发送到客户端的应用程序。

事实上，API不仅用于发送数据，而且并不总是与Web开发、javascript、python或任何编程语言或框架相关。

API中的应用实际上可以意味着许多不同的东西，只要软件是相对独立的。例如，文件系统或HTTP模块，我们可以说它们是软件的一小部分，我们可以使用它们，我们可以通过使用它们的API与它们交互。例如，当我们对任何编程语言的文件系统模块使用read file函数时，我们实际上使用的是file_system_readingAPI。或者当我们在浏览器中进行DOM操作时，我们并没有真正使用JavaScript语言本身，而是浏览器向我们公开的DOM API，所以它允许我们访问它。或者另一个例子，假设我们用任何编程语言创建了一个类，比如Java然后向其添加一些公共方法或属性，这些方法将成为从该类创建的每个对象的API，因为我们为其他软件提供了与我们最初的软件交互的可能性，在这种情况下是对象。S0，API实际上比构建Web API更广泛。

现在让我们来看看构建API的REST架构。

代表具象状态传输的REST基本上是一种以逻辑方式构建Web API的方式，使它们易于为我们自己或他人使用。

要按照REST架构构建RESTful API，我们只需要遵循几个原则。1.我们需要将我们的API拆分为逻辑资源。2.然后应使用基于资源的URL公开这些资源。3.要对数据执行不同的操作，例如读取、创建或删除数据，API应该使用正确的HTTP方法而不是URL。4.现在我们实际发送回客户端或从客户端收到的数据通常应该使用JSON数据格式，并应用了一些格式标准。5.最后，EST API的另一个重要原则是它们必须是无状态的。

将API分离为逻辑资源： REST中信息的关键抽象是一个资源，因此我们想要在API中共享的所有数据都应该被划分为逻辑资源。什么是资源？在REST的上下文中，它是一个对象或某物的表示，其中包含一些与之相关的数据。例如，像导游旅游这样的应用程序，或用户、地点或评论就是逻辑资源的例子。所以基本上任何可以命名的信息都可以是资源。只是必须命名，而不是动词。

暴露结构：现在我们需要公开，这意味着使用一些结构化的URL使数据可用，客户端可以向其发送请求。例如，像这样的整个地址称为URL。这个/addNewTour被调用和API端点。

我们的API将有许多不同的端点，就像Bellow一样

https://www.tourguide.com/addNewTourhttps://www.tourguide.com/getTourhttps://www.tourguide.com/updateTourhttps://www.tourguide.com/deleteTourhttps://www.tourguide.com/getRoursByUserhttps://www.tourguide.com/deleteToursByUser

这些API中的每一个都会在执行不同的操作时将不同的数据发送回客户端。现在这里有非常错误的事情的这些端点，因为它们真的不遵循第三条规则，即我们应该只使用HTTP方法来对数据执行操作。因此端点应该只包含我们的资源，而不是我们对它们执行的操作，因为它们很快就会成为维护的噩梦。

在实践中我们应该如何使用这些HTTP方法？让我们看看这些端点实际上应该是以 /getTour.开始的样子所以这个getTour端点是为了获取有关旅游的数据，所以我们应该简单地命名端点 /tours并在向该端点发出get请求时发送数据。所以换句话说，当客户端使用GET HTTP方法访问端点时，

（我们只有端点或URL中的资源，没有动词，因为动词现在在HTTP方法中，对吗？通常的做法是总是使用复数的资源名称，这就是为什么我写 /tours也不 /tour.）惯例是，当调用端点时 /tours将返回数据库中的所有旅游，但如果我们只想要一个ID的旅游，比方说7，我们在另一个斜杠（/旅游/7）或搜索查询（/旅游？id=7）中添加7，当然，它也可以是旅游的名称而不是ID。

HTTP方法：这里真正重要的是端点名称如何与所有端点名称完全相同。

GET: (for requesting data from the server.) https://www.tourguide.com/tours/7POST: (for sending data to the server.)https://www.tourguide.com/toursPUT/PATCH: (for updating requests for data to the server.) https://www.tourguide.com/tours/7DELETE: (for deleting request for data to the server.)https://www.tourguide.com/tours/7

PUT和PATCH->的区别通过使用PUT，客户端应该发送整个更新的对象，而使用PATCH，它应该只发送已更改的对象的一部分。

通过使用HTTP方法，用户可以执行基本的四种CRUD操作，CRUD代表创建、读取、更新和删除。

现在可能会出现如下情况：

所以， /getToursByUser可以简单地被翻译成 /users/tours，对于3号终端的用户将是 /users/3/tours.

如果我们想删除特定用户的特定旅游，那么URL应该像 /users/3/tours/7，这里的用户ID： 3和旅游ID： 7。

因此，确实有大量的可能性来组合这样的资源。

以JSON格式发送数据：现在关于客户端实际接收的数据，或者服务器从客户端接收的数据，通常我们使用JSON数据格式。一个典型的JSON可能如下所示：在发送JSON数据之前，我们通常会做一些简单的响应格式设置，这有几个标准，但其中一个非常简单的标准称为Jend。我们只需创建一个新对象，然后向其添加一条状态消息，以便通知客户端请求是成功、失败还是错误。然后我们将原始数据放入一个名为Data的新对象中。

像我们在这里所做的那样将数据包装到一个附加对象中称为包络，这是缓解一些安全问题和其他问题的常见做法。

RESTful API应该始终是无状态的：最后，RESTful API应该始终是无状态的，这意味着在无状态的RESTful API中，所有状态都在客户端处理，而不是在服务器上处理。状态只是指应用程序中可能随时间变化的一段数据。例如，某个用户是否登录或在具有多个页面的列表的页面上当前页面是什么？现在，状态应该在客户端处理的事实意味着每个请求都必须包含在服务器上处理某个请求所需的所有信息。因此，服务器永远不应该为了处理当前请求而记住前一个请求。

假设我们现在在第5页，我们想前进到第6页。现在我们可以有一个名为 /tours/nextPage的简单端点并向服务器提交请求，但服务器必须弄清楚当前页面是什么，然后服务器将根据该页面向客户端发送下一页。换句话说，服务器必须记住上一个请求。这正是我们在RESTful API中想要避免的。

在这种情况下，我们应该创建一个 /tours/page端点并将数字6粘贴到其中，以便请求第6页 /tours/page/6。因此服务器不必记住任何内容，它所要做的就是按照我们的请求发回第6页的数据。

无状态和状态相反是计算机科学和一般应用中非常重要的概念

小开

为了在这里贡献一些新的东西，我想分享我的文章的链接，通过一种实用和客观的方法概念化REST。
我涵盖了主要概念，如：
HATEOAS-超媒体作为应用程序状态的引擎，
资源和陈述，
可寻址性，
REST中的幂等性，
理查森的REST成熟度模型。
媒体类型
api版本控制
我还创建了一个GitHub项目，您可以使用docker轻松运行，其中涵盖了我在本文中介绍的内容。
https://itnext.io/how-to-build-a-restful-api-a-deep-dive-into-rest-apis-215188f80854