这是我对REST的基本概述。我试图演示RESTful架构中每个组件背后的思想，以便更直观地理解概念。希望这有助于为某些人揭开REST的神秘面纱！

REST（代表性状态转移）是一种设计架构，它概述了网络资源（即共享信息的节点）的设计和寻址方式。一般来说，RESTful体系结构使得客户端（请求机器）和服务器（响应机器）可以请求读取、写入和更新数据，而客户端不必知道服务器是如何操作的，并且服务器可以在不需要了解客户端的任何信息的情况下将数据传递回去。好吧，酷。。。但我们如何在实践中做到这一点？

最明显的要求是需要有某种通用语言，以便服务器可以告诉客户端它正在尝试如何处理请求，并让服务器做出响应。但是，要找到任何给定的资源，然后告诉客户该资源所在的位置，需要有一种指向资源的通用方法。这就是通用资源标识符（URI）的作用；它们基本上是查找资源的唯一地址。

但REST架构并没有就此结束！虽然以上内容满足了我们所需的基本需求，但我们也希望拥有一个支持高流量的体系结构，因为任何给定的服务器通常都会处理来自多个客户端的响应。因此，我们不想让服务器记住以前请求的信息，从而使服务器不堪重负。

因此，我们施加了一个限制，即客户端和服务器之间的每个请求-响应对都是独立的，这意味着服务器不必记住以前的请求（客户端-服务器交互的以前状态）来响应新请求。这意味着我们希望我们的交互是无状态的。为了进一步减轻我们的服务器因重做最近已为给定客户端完成的计算而承受的压力，REST还允许缓存。基本上，缓存意味着对提供给客户端的初始响应进行快照。如果客户端再次发出相同的请求，服务器可以向客户端提供快照，而不是重做创建初始响应所需的所有计算。但是，由于它是一个快照，如果快照尚未过期（服务器提前设置了过期时间），并且响应自初始缓存以来已更新（即请求将给出与缓存响应不同的答案），则客户端将不会看到更新，直到缓存过期（或缓存被清除），并且再次从头开始呈现响应。关于RESTful架构，最后一件事是它们是分层的。实际上，我们已经在讨论客户端和服务器之间的交互时隐式地讨论了这个需求。基本上，这意味着我们系统中的每个层只与相邻层交互。因此，在我们的讨论中，客户端层与服务器层交互（反之亦然），但可能有其他服务器层帮助主服务器处理客户端不直接通信的请求。相反，服务器根据需要传递请求。

现在，如果所有这些听起来都很熟悉，那就太好了。超文本传输协议（HTTP）定义了通过万维网的通信协议，它是RESTful架构抽象概念的一种实现（如果你像我一样是OOP狂热者，则是抽象REST类的实现）。在REST的这个实现中，客户端和服务器通过GET、POST、PUT、DELETE等进行交互，这些都是通用语言的一部分，可以使用URL指向资源。

Edit

阅读这里的自述文件，我希望你真的能得到REST。

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

--

这些给出链接资源示例的答案很好，但只占一半。

所以，想象你正在设计一个网站。你写一个故事，

我希望能够通过邮政编码搜索地址，以便选择发货地址

然后，您将构建网站，让用户踏上旅程，并尝试在工作流中将页面链接在一起。

一个网站设计让他们进行地址查找，然后让他们将地址复制到剪贴板，然后返回到发货地址表单，这是不太有用的。

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

对邮政编码功能的搜索不应该是base/addresss/{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。

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

之所以创建RESTful一词，是因为ppl通过将其非REST应用程序称为REST而耗尽了REST一词。此后，RESTful一术语也耗尽了。现在我们讨论的是Web API和超媒体API，因为大多数所谓的REST应用程序都没有实现统一接口约束的HATEOAS部分。

REST约束如下：

客户端-服务器体系结构因此，它不适用于例如PUB/SUB套接字，而是基于REQ/REP。无状态通信因此，服务器不维护客户端的状态。这意味着您不能使用服务器侧会话存储，并且必须对每个请求进行身份验证。您的客户端可能通过加密连接发送基本身份验证标头。（对于大型应用程序，很难维护许多会话。）如果可以，请使用缓存因此，您不必一次又一次地满足相同的请求。作为客户机和服务器之间通用契约的统一接口客户端和服务器之间的契约不由服务器维护。换句话说，客户端必须与服务的实现分离。您可以通过使用标准解决方案来达到这种状态，例如用于标识资源的IRI（URI）标准、用于交换消息的HTTP标准、用于描述消息体序列化格式的标准MIME类型、用于描述邮件体不同部分语义的元数据（可能是RDF vocabs、微格式等）。为了将IRI结构与客户端分离，必须以超媒体格式（HTML、JSON-LD、HAL等）向客户端发送超链接。因此，客户端可以使用分配给超链接的元数据（可能是链接关系、RDF vocabs），通过适当的状态转换来导航应用程序的状态机，以实现其当前目标。例如，当客户想要向网络商店发送订单时，必须检查网络商店发送的响应中的超链接。通过检查链接，可以找到http://schema.org/OrderAction.客户机知道schema.org vocab，因此它知道通过激活这个超链接，它将发送订单。因此它激活超链接并发送POSThttps://example.com/api/v1/order以恰当的方式传递信息。之后，服务处理消息并以具有正确HTTP状态标头的结果进行响应，例如201-由成功创建。为了用详细的元数据注释消息，标准解决方案使用RDF格式，例如JSON-LD和REST vocab，例如Hydra和领域特定vocab（如schema.org或任何其他链接数据vocab），如果需要，还可以使用定制的应用程序特定vocab。现在这并不容易，这就是为什么大多数应用程序使用HAL和其他简单格式，这些格式通常只提供REST vocab，但不提供链接数据支持。构建分层系统以提高可扩展性REST系统由层次结构层组成。每一层包含使用下一层组件的服务的组件。因此，您可以轻松添加新的图层和组件。例如，有一个包含客户端的客户端层，在该层之下有一个服务层，该服务层包含单个服务。现在，您可以在它们之间添加客户端缓存。之后，您可以添加另一个服务实例和负载平衡器等…客户端代码和服务代码不会更改。扩展客户端功能的按需代码此约束是可选的。例如，您可以向客户端发送特定媒体类型的解析器，等等…为了做到这一点，您可能需要客户端中的标准插件加载器系统，或者您的客户端将耦合到插件加载器解决方案。

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

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

这里有一个很好的例子：

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

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

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

看完这些例子后，我明白了Ken为什么说REST是超文本驱动的。但我实际上并不确定他是对的，因为/user/123是指向资源的URI，我不清楚它是否是非RESTful的，因为客户端知道它是“带外”的

xfront文档解释了REST和SOAP之间的区别，这也非常有用。当Fielding说：“这是RPC。它尖叫RPC。”时，很明显RPC不是RESTful的，所以了解这一点的确切原因很有用。（SOAP是RPC的一种类型。）

一种称为REST（RepresentationalStateTransfer）的体系结构风格主张web应用程序应该像最初设想的那样使用HTTP。查找应使用GET请求。PUT、POST和DELETE请求应分别用于变异、创建和删除。

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请求。

这摘自大卫·M·Geary的优秀著作《核心JavaServer面孔》。

什么是REST？

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

原则1：一切都是资源在REST体系结构风格中，数据和功能被视为资源，并使用统一资源标识符（URI）（通常是Web上的链接）进行访问。原则2：每个资源都由唯一标识符（URI）标识原则3：使用简单统一的接口原则4：通过代表进行沟通原则5：无状态