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架构的架构重要性和性能含义，最重要的技巧是避免被技术和实现细节所困扰。关注谁拥有资源，谁负责创建/维护资源等。然后思考表示、协议和技术。

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

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

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

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

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

与家庭风格不同的REST在持续和实际应用中遇到了困难。这可能是故意的。将其实际实现留给设计者。所以你可以自由地做你想做的事情，只要你满足论文中提出的约束条件，你就可以创建REST系统。

奖金：

整个web都基于REST（或REST基于web）。因此，作为一名web开发人员，您可能需要意识到这一点，尽管编写好的web应用程序并不必要。

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

罗伊·菲尔丁（Roy Fielding）创造了这个术语，他表示RESTAPI必须是超文本驱动的。特别是，“REST API不能定义固定的资源名称或层次结构”。

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

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

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

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

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

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

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

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

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

例如，取而代之的是一组URL，可能看起来像下面的一些。。

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

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

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