剩下的一点是，如果我们同意对基本操作使用通用语言（http动词），那么可以配置基础结构来理解它们并适当地优化它们，例如，通过使用缓存头在所有级别实现缓存。

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

说Rest只是语法上的改变，从使用带有动作参数的GET请求到使用可用的http动词，这看起来没有任何好处，而且纯粹是修饰。重点是使用一种可以被链的每个部分理解和优化的语言。如果GET操作有副作用，则必须跳过所有HTTP缓存，否则结果将不一致。

什么是REST？REST代表代表性状态转移。（有时拼写为“ReST”。）它依赖于无状态的、可缓存的客户端服务器通信协议——实际上在所有情况下，都是HTTP使用协议。REST是一种用于设计网络应用程序的架构风格。其思想是，使用RPC或SOAP连接机器，使用简单的HTTP机器之间的呼叫。在许多方面，可以查看基于HTTP的万维网本身作为基于REST的架构。RESTful应用程序使用HTTP请求发布数据（创建和/或更新）、读取数据（例如，并删除数据。因此，REST对所有四个CRUD使用HTTP（创建/读取/更新/删除）操作。REST是RPC（远程过程调用）和Web服务（SOAP、WSDL等）看看REST有多简单。尽管REST很简单，但它功能齐全；基本上有在Web服务中，没有什么是RESTful无法完成的建筑学REST不是“标准”。永远不会有W3C例如REST推荐。尽管有REST编程框架，使用REST非常简单通常使用诸如Perl、Java或C#。

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

http://rest.elkstein.org/

如果我不得不将关于REST的原始论文缩减为短短的3句话，我认为以下内容抓住了它的精髓：

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

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

有趣的是，本文中没有提到HTTPPOST、GET、DELETE或PUT操作。这一定是后来有人对“统一界面”的“最佳实践”的解释。

当涉及到web服务时，我们似乎需要一些方法来区分WSDL和基于SOAP的体系结构，这会给接口增加相当大的开销和不必要的复杂性。它们还需要额外的框架和开发人员工具才能实现。我不确定REST是否是区分常识接口和过度工程化接口（如WSDL和SOAP）的最佳术语。但我们需要一些东西。

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

没有从以前的通信中携带的信息或记忆。因此，每次客户端与后端交互时，它都必须向其发送身份验证信息。这使后端能够确定客户端是否有权访问数据。

通过REST API的实现，客户端可以获得要与之通信的后端端点。这完全分离了后端和客户端代码。

答案很简单，罗伊·菲尔丁写了一篇论文。]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年，我们最终被天网终止。在此之前…；-）

RESTful编程是关于：

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

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

如果你真的对RESTful架构是什么以及它为什么工作感兴趣，请读几遍他的论文，并阅读整个内容，而不仅仅是第5章！接下来看看DNS为什么工作。阅读DNS的分级组织以及转介的工作原理。然后阅读并考虑DNS缓存的工作原理。最后，阅读HTTP规范（尤其是RFC2616和RFC3040），并考虑高速缓存的工作方式及其原因。最终，它只会咔嚓一声。当我看到DNS和HTTP之间的相似性时，我得到了最后的启示。在这之后，了解SOA和消息传递接口是可伸缩的就开始了。

我认为，要理解RESTful和SharedNothing架构的架构重要性和性能含义，最重要的技巧是避免被技术和实现细节所困扰。关注谁拥有资源，谁负责创建/维护资源等。然后思考表示、协议和技术。