What exactly is RESTful programming?
RESTful编程到底是什么？
REST是Web的基础架构原则。Web的惊人之处在于，客户机(浏览器)和服务器可以以复杂的方式进行交互，而客户机不必事先了解服务器及其承载的资源。关键限制是服务器和客户机必须在所使用的媒体上达成一致，在Web的情况下，这是HTML。
遵循REST原则的API不需要客户机了解API的结构。相反，服务器需要提供客户机与服务交互所需的任何信息。HTML表单就是这样一个例子：服务器指定资源的位置和必需的字段。浏览器不预先知道在哪里提交信息，也不预先知道要提交什么信息。这两种形式的信息都完全由服务器提供。(这一原则被称为hateoas：作为应用程序状态引擎的超媒体。)
那么，这如何应用于HTTP，以及如何在实践中实现它？HTTP面向动词和资源。主流用法中的两个动词是
例如，假设我们有一个由Web服务管理的用户数据库。我们的服务使用基于JSON的自定义超媒体，为此我们分配mimetype
A REST API should spend almost all of its descriptive effort in
defining the media type(s) used for representing resources and driving
application state, or in defining extended relation names and/or
hypertext-enabled mark-up for existing standard media types.
对基础资源
请求
1 2 | GET / Accept: application/json+userdb |
响应
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | 200 OK Content-Type: application/json+userdb { "version":"1.0", "links": [ { "href":"/user", "rel":"list", "method":"GET" }, { "href":"/user", "rel":"create", "method":"POST" } ] } |
我们从媒体的描述中知道，我们可以从"链接"部分找到有关资源的信息。这叫做超媒体控制。在这种情况下，我们可以从这样一个部分看出，我们可以通过对
请求
1 2 | GET /user Accept: application/json+userdb |
响应
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 | 200 OK Content-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" } ] } |
我们可以从这个回答中看出很多。例如，我们现在知道可以通过
请求
1 2 3 4 5 6 7 8 | POST /user Accept: application/json+userdb Content-Type: application/json+userdb { "name":"Karl", "country":"Austria" } |
响应
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | 201 Created Content-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" } } |
我们还知道，我们可以更改现有数据：
请求
1 2 3 4 5 6 7 8 | PUT /user/1 Accept: application/json+userdb Content-Type: application/json+userdb { "name":"Emil", "country":"Bhutan" } |
响应
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | 200 OK Content-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动词(
进一步阅读：
- 在这一页上有很多更好的答案。
我如何向我妻子解释休息。- 我如何向我妻子解释休息。
- Martin Fowler思想
- PayPal的API具有超媒体控件
(这一回答因遗漏了要点而受到了相当多的批评。在很大程度上，这是一个公平的批评。我最初描述的更符合几年前我第一次写这篇文章时REST通常是如何实现的，而不是它的真正含义。我修改了答案，以便更好地表达真实的含义。)
一种称为REST(代表性状态转移)的体系结构风格主张Web应用程序应该像最初设想的那样使用HTTP。查找应使用
REST支持者倾向于使用URL，例如
1 | http://myserver.com/catalog/item/1729 |
但是，其余的体系结构不需要这些"漂亮的URL"。带有参数的GET请求
1 | http://myserver.com/catalog?item=1729 |
一切都那么安逸。
请记住，GET请求不应用于更新信息。例如，将项目添加到购物车的GET请求
1 | http://myserver.com/addToCart?cart=314159&item=1729 |
不合适。GET请求应该是等幂的。也就是说，发出两次请求和发出一次请求应该没有什么不同。这就是使请求可缓存的原因。"添加到购物车"请求不是等量的，发出两次请求会将项目的两个副本添加到购物车。在这种情况下，发布请求显然是合适的。因此，即使是一个RESTful的Web应用程序也需要它的POST请求份额。
这是摘自大卫·M·盖瑞的优秀著作《核心JavaServer Faces》。
RESTful编程是关于：
- 由持久标识符标识的资源：目前，URI是无处不在的标识符选择
- 使用一组常见的动词来操纵资源：HTTP方法是常见的情况——受人尊敬的
Create 、Retrieve 、Update 、Delete 变成POST 、GET 、PUT 和Delete 。但REST不局限于HTTP，它只是目前最常用的传输。 - 为资源检索的实际表示依赖于请求而不是标识符：使用Access标头来控制是否需要XML、HTTP或甚至代表资源的Java对象。
- 在对象中维护状态并在表示中表示状态
- 表示资源表示中资源之间的关系：对象之间的链接直接嵌入表示中
- 资源表示描述如何使用表示，以及在什么情况下应以一致的方式丢弃/重新蚀刻表示：HTTP缓存控制头的使用
最后一个可能是在后果和休息的整体效果方面最重要的。总的来说，大多数RESTful的讨论似乎都集中在HTTP及其在浏览器中的使用以及其他方面。我知道R.Fielding在描述导致HTTP的体系结构和决策时创造了这个术语。与HTTP相比，本文更关注资源的体系结构和缓存能力。
如果你真的对一个宁静的建筑是什么以及为什么它能工作感兴趣的话，可以读几遍他的论文，并阅读整个内容，而不仅仅是第5章！下一步研究DNS工作的原因。请阅读有关DNS的分层组织以及引用如何工作的信息。然后阅读并考虑DNS缓存是如何工作的。最后，阅读HTTP规范(特别是rfc2616和rfc3040)，并考虑缓存如何以及为什么以这种方式工作。最终，它只会点击。对我来说，最后的启示是当我看到dns和http之间的相似性时。在这之后，了解SOA和消息传递接口为什么是可伸缩的开始点击。
我认为理解RESTful和无共享体系结构的体系结构重要性和性能影响的最重要技巧是避免被技术和实现细节所困扰。专注于谁拥有资源，谁负责创建/维护资源等，然后考虑表示、协议和技术。
这就是它可能的样子。
创建具有三个属性的用户：
1 2 | POST /user fname=John&lname=Doe&age=25 |
服务器响应：
1 2 | 200 OK Location: /user/123 |
以后，您可以检索用户信息：
1 | GET /user/123 |
服务器响应：
1 2 | 200 OK <fname>John</fname><lname>Doe</lname>25</age> |
要修改记录(
1 2 | PATCH /user/123 fname=Johnny |
要更新记录(因此，
1 2 | PUT /user/123 fname=Johnny |
一本关于休息的好书就是实践中的休息。
必须读取是表示状态传输(REST)，并且RESTAPI必须是超文本驱动的
请参阅MartinFowlers文章Richardson成熟度模型(RMM)，了解关于什么是RESTful服务的解释。
为了保证服务的安全，需要将超媒体作为应用程序状态的引擎来实现。(hateoas)，也就是说，它需要达到RMM中的3级，阅读文章了解细节或Qcon谈话的幻灯片。
The HATEOAS constraint is an acronym
for Hypermedia as the Engine of
Application State. This principle is
the key differentiator between a REST
and most other forms of client server
system....
A client of a RESTful application need
only know a single fixed URL to access
it. All future actions should be
discoverable dynamically from
hypermedia links included in the
representations of the resources that
are returned from that URL.
Standardized media types are also
expected to be understood by any
client that might use a RESTful API.
(From Wikipedia, the free encyclopedia)
Web框架的rest-litmus测试与Web框架的成熟度测试类似。
接近纯粹的休息：学习爱恨恶是一个很好的链接集合。
针对公共云的REST与SOAP讨论了当前的REST使用级别。
REST和版本控制讨论了可扩展性、版本控制、可演化性等。通过可修改性
型
What is REST?
REST stands for Representational State Transfer. (It is sometimes
spelled"ReST".) It relies on a stateless, client-server, cacheable
communications protocol -- and in virtually all cases, the HTTP
protocol is used.REST is an architecture style for designing networked applications.
The idea is that, rather than using complex mechanisms such as CORBA,
RPC or SOAP to connect between machines, simple HTTP is used to make
calls between machines.In many ways, the World Wide Web itself, based on HTTP, can be viewed
as a REST-based architecture. RESTful applications use HTTP requests
to post data (create and/or update), read data (e.g., make queries),
and delete data. Thus, REST uses HTTP for all four CRUD
(Create/Read/Update/Delete) operations.REST is a lightweight alternative to mechanisms like RPC (Remote
Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will
see how much more simple REST is.Despite being simple, REST is fully-featured; there's basically
nothing you can do in Web Services that can't be done with a RESTful
architecture. REST is not a"standard". There will never be a W3C
recommendataion for REST, for example. And while there are REST
programming frameworks, working with REST is so simple that you can
often"roll your own" with standard library features in languages like
Perl, Java, or C#.
号
当我试图找到休息的简单真正意义时，我发现了一个最好的参考。
http://rest.elkstein.org网站/
REST使用各种HTTP方法(主要是get/put/delete)来操作数据。
不是使用特定的URL来删除方法(例如，
例如，取而代之的是一组URL，它们可能看起来像下面的一些。
1 2 3 4 5 6 | 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"verbs"并使用..
1 2 3 | GET /user/2 DELETE /user/2 PUT /user |
这是一个程序设计，你的系统架构符合罗伊·菲尔丁在他的论文中提出的休息风格。因为这是描述网络的架构风格(或多或少)，所以很多人都对它感兴趣。
奖励答案：没有。除非你正在学习软件架构作为学术或设计Web服务，否则真的没有理由听过这个词。
如果我没有直接回答这个问题，我很抱歉，但是通过更详细的例子更容易理解这一切。由于所有的抽象和术语，字段化并不容易理解。
这里有一个很好的例子：
解释REST和超文本：垃圾邮件清理机器人
更棒的是，这里有一个简单的例子解释清楚(PowerPoint更全面，但您可以在HTML版本中获得大部分内容)：
http://www.xfront.com/rest.ppt或http://www.xfront.com/rest.html
在阅读了这些例子之后，我明白了为什么肯说REST是超文本驱动的。不过，我并不确定他是否正确，因为/user/123是一个指向资源的URI，我也不清楚，它之所以没有效果，仅仅是因为客户端"带外"知道它。
XFront文档解释了REST和SOAP之间的区别，这也非常有用。当菲尔丁说，"那是RPC。它尖叫着"rpc"，很明显，rpc是不可休息的，所以看到确切的原因是很有用的。(SOAP是一种RPC。)
型
我会说RESTful编程是关于创建遵循REST体系结构风格的系统(API)。
我发现M.Elkstein博士的这篇关于休息的精彩、简短且易于理解的教程，并引用了最基本的部分来回答您的问题：
学习休息：教程
REST is an architecture style for designing networked applications.
The idea is that, rather than using complex mechanisms such as CORBA,
RPC or SOAP to connect between machines, simple HTTP is used to make
calls between machines.
- In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.
RESTful applications use HTTP requests to post data (create and/or
update), read data (e.g., make queries), and delete data. Thus, REST
uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.
号
我认为你不应该因为没有听到堆栈溢出之外的休息而感到愚蠢…，我会处于同样的情况！回答另一个问题，为什么现在休息变得更大可以缓解一些感觉。
休息是什么？
用官方的话说，REST是一种基于某些原则的架构风格，使用当前的"Web"基本原理。Web有5个基本原理，用于创建REST服务。
- 原则1：一切都是资源在REST体系结构样式中，数据和功能被视为资源，并使用统一资源标识符(URI)访问，通常是Web上的链接。
- 原则2：每个资源都由唯一标识符(URI)标识。
- 原则3：使用简单统一的接口
- 原则4：通过代表进行沟通
- 原则5：无状态
我看到了一堆答案，它们说将用户123的所有内容放在资源"/user/123"上是可以休息的。
RoyFielding创造了这个术语，他说RESTAPI必须是超文本驱动的。特别是，"RESTAPI不能定义固定的资源名称或层次结构"。
因此，如果您的"/user/123"路径是硬编码在客户机上的，那么它就不是真正的RESTful。很好地使用HTTP，也许，也许不是。但不能休息。它必须来自超文本。
答案很简单，有一篇由罗伊·菲尔丁写的论文。]1在这篇论文中，他定义了其余的原则。如果一个应用程序满足所有这些原则，那么它就是一个REST应用程序。好的。
之所以创建restful一词，是因为PPL通过将非rest应用程序调用为rest耗尽了单词rest。在那之后，restful这个词也被耗尽了。现在我们讨论的是Web API和超媒体API，因为大多数所谓的REST应用程序都没有满足统一接口约束的hateoas部分。好的。
其余约束如下：好的。
客户机-服务器体系结构好的。
所以它不适用于pub/sub套接字，它基于req/rep。好的。
无状态通信好的。
所以服务器不维护客户机的状态。这意味着您不能使用服务器端会话存储，必须对每个请求进行身份验证。您的客户机可能通过加密连接发送基本的认证头。(对于大型应用程序，很难维护许多会话。)好的。
如果可以，使用缓存好的。
所以你不必一次又一次地满足同样的要求。好的。
统一接口作为客户机和服务器之间的公共契约好的。
客户机和服务器之间的契约不由服务器维护。换句话说，客户机必须与服务的实现分离。您可以通过使用标准解决方案(如IRI(URI)标准来标识资源、HTTP标准来交换消息、标准的mime类型来描述主体序列化格式、元数据(可能是RDF词汇、微格式等)来描述消息主体不同部分的语义来达到这种状态。要将IRI结构与客户机分离，必须以超媒体格式(HTML、JSON-LD、HAL等)向客户机发送超链接。因此，客户机可以使用分配给超链接的元数据(可能是链接关系、RDF词汇)，通过适当的状态转换来导航应用程序的状态机，以实现其当前目标。好的。型
例如，当一个客户机想要向一个webshop发送一个订单时，它必须检查webshop发送的响应中的超链接。通过检查链接，它找到了一个用http://schema.org/orderaction描述的链接。客户机知道schema.org词汇表，因此它了解通过激活这个超链接，它将发送订单。所以它激活了超链接，并用适当的主体发送一条
构建分层系统以提高可扩展性好的。型
其余系统由层次层组成。每一层都包含使用下一层组件服务的组件。因此，您可以轻松地添加新的层和组件。好的。型
例如，有一个包含客户机的客户机层，下面是一个包含单个服务的服务层。现在您可以在它们之间添加客户端缓存。之后，您可以添加另一个服务实例和负载平衡器，等等…客户端代码和服务代码不会更改。好的。型百万千克1百万千克1
按需编码以扩展客户端功能好的。型
此约束是可选的。例如，您可以向客户机发送特定媒体类型的解析器，等等…为了做到这一点，您可能需要在客户机中使用一个标准的插件加载程序系统，否则您的客户机将与插件加载程序解决方案耦合。好的。型百万千克1
REST约束导致了一个高度可扩展的系统，其中客户机与服务实现分离。因此客户机可以重复使用，就像Web上的浏览器一样。客户机和服务共享相同的标准和词汇，因此尽管客户机不知道服务的实现细节，但他们可以相互理解。这使得创建自动化客户机成为可能，这些客户机可以找到并利用REST服务来实现他们的目标。从长远来看，这些客户机可以像人类一样，通过任务相互沟通和信任。如果我们向这些客户机添加学习模式，那么结果将是一个或多个使用机器网络的人工智能，而不是一个单一的服务器园区。因此，在最后，伯纳斯李的梦想：语义网和人工智能将成为现实。所以在2030年，我们最终被天网终止。直到那时…；-)好的。型好啊。
RESTful(代表性状态转移)API编程是通过以下5种基本的软件体系结构风格原则，以任何编程语言编写Web应用程序：
换句话说，您正在通过HTTP编写简单的点对点网络应用程序，它通过实现RESTful体系结构来使用诸如get、post、put或delete等动词，该体系结构提出了每个"资源"公开的接口的标准化。以一种简单有效的方式(高度成功、经验证和分布式的体系结构)使用Web的当前功能，这是无济于事的。它是SOAP、CORBA和RPC等更复杂机制的替代方案。
RESTful编程符合Web体系结构设计，如果实现得当，它允许您充分利用可扩展的Web基础结构。
型
REST是一种体系结构模式和编写分布式应用程序的风格。它不是狭义上的编程风格。
说你使用休息的风格类似于说你建造了一个特殊的风格的房子：例如都铎式或维多利亚式。软件风格的休息和家庭风格的都铎或维多利亚都可以由构成它们的品质和约束来定义。例如，REST必须有客户机-服务器分离，其中消息是自描述的。都铎风格的房子有重叠的山墙和屋顶，它们与前面的山墙形成陡峭的倾斜。你可以阅读罗伊的论文来了解更多关于构成休息的约束和品质的知识。
与家庭风格不同的是，在坚持和实际应用方面，休息是很困难的。这可能是故意的。将其实际实现留给设计人员。所以你可以自由地做你想做的事情，只要你满足论文中提出的限制条件，你就可以创建REST系统。
奖金：
整个网络基于REST(或REST基于Web)。因此，作为一个Web开发人员，您可能希望了解这一点，尽管不必编写好的Web应用程序。
这是我休息的基本情况。我试图在一个RESTful体系结构中演示每个组件背后的思想，以便更直观地理解概念。希望这能帮助一些人揭开休息的神秘面纱！
REST(代表性状态转移)是一种设计架构，它概述了如何设计和处理网络资源(即共享信息的节点)。一般来说，RESTful体系结构使得客户机(请求机)和服务器(响应机)可以请求读取、写入和更新数据，而客户机不必知道服务器是如何运行的，服务器也可以在不需要了解客户机的任何情况下将其传回。好的，很酷……但是我们如何在实践中做到这一点？
最明显的要求是，需要某种通用语言，以便服务器能够告诉客户机它试图对请求做什么，并让服务器作出响应。
但是，要找到任何给定的资源，然后告诉客户该资源在哪里，需要有一种通用的指向资源的方法。这就是通用资源标识符(uri)出现的地方；它们基本上是查找资源的唯一地址。
但其余的建筑并没有就此结束！虽然上面的内容满足了我们所需要的基本需求，但是我们还希望拥有一个支持高流量的体系结构，因为任何给定的服务器通常处理来自多个客户机的响应。因此，我们不希望让服务器记住有关以前请求的信息，从而压倒服务器。
因此，我们对客户机和服务器之间的每个请求-响应对都进行了限制，这意味着服务器不必记住任何有关以前的请求(客户机-服务器交互的以前状态)的信息来响应新的请求。这意味着我们希望我们的交互是无状态的。
为了进一步减轻服务器上重做最近为给定客户机所做的计算的压力，REST还允许缓存。基本上，缓存意味着获取提供给客户机的初始响应的快照。如果客户机再次发出相同的请求，服务器可以向客户机提供快照，而不是重做创建初始响应所需的所有计算。但是，由于它是一个快照，如果快照没有过期——服务器预先设置了一个过期时间——并且响应在初始缓存(即请求将给出一个与缓存响应不同的响应)之后进行了更新，则在缓存过期(或缓存被清除)和响应之前，客户端将看不到更新。重新从头开始渲染。
关于RESTful架构，您在这里经常遇到的最后一件事是它们是分层的。实际上，在讨论客户机和服务器之间的交互时，我们已经隐式地讨论了这个需求。基本上，这意味着系统中的每一层只与相邻的层交互。因此，在我们的讨论中，客户机层与服务器层交互(反之亦然)，但可能还有其他服务器层帮助主服务器处理客户机不直接通信的请求。相反，服务器根据需要传递请求。
现在，如果所有这些听起来都很熟悉，那就太好了。超文本传输协议(HTTP)定义了通过万维网的通信协议，它是RESTful体系结构抽象概念的实现(如果您是像我这样的OOP狂热者，则是REST类的实例)。在REST的这个实现中，客户机和服务器通过GET、POST、PUT、DELETE等进行交互，这是通用语言的一部分，资源可以指向使用URL的地方。
如果我不得不将原来的论文的休息时间缩短为3个简短的句子，我认为以下内容抓住了它的本质：
之后，很容易陷入关于适应性、编码约定和最佳实践的争论中。
有趣的是，本文中没有提到http-post、get、delete或put操作。这一定是后来有人对"统一接口"的"最佳实践"的解释。
当涉及到Web服务时，我们似乎需要某种方法来区分基于WSDL和SOAP的体系结构，这会给接口增加相当大的开销，并且可能会增加很多不必要的复杂性。它们还需要额外的框架和开发人员工具来实现。我不确定REST是否是区分常识接口和过度设计的接口(如WSDL和SOAP)的最佳术语。但我们需要一些东西。
我认为RESTful的要点是将状态分离为更高的层，同时将Internet(协议)用作无状态传输层。大多数其他方法都是混淆的。
它是处理互联网时代编程的根本变化的最佳实践方法。关于基本变化，Erik Meijer在以下网站上进行了讨论：http://www.infoq.com/interfaces/erik Meijer programming language design effects purity_view_93197。他将其总结为五种效果，并通过将解决方案设计成编程语言来提出解决方案。解决方案，也可以在平台或系统级别实现，无论语言如何。RESTful可以看作是当前实践中非常成功的解决方案之一。
使用RESTful样式，您可以通过不可靠的Internet获取和操作应用程序的状态。如果当前操作无法获得正确的当前状态，则需要零验证主体来帮助应用程序继续。如果它不能操纵状态，它通常使用多个确认阶段来保持事物的正确性。从这个意义上讲，REST本身并不是一个完整的解决方案，它需要Web应用程序堆栈的其他部分中的函数来支持它的工作。
鉴于这种观点，REST样式实际上并不与Internet或Web应用程序相关联。它是许多编程情况的基本解决方案。它也不简单，它只是让界面变得非常简单，并且能够很好地处理其他技术。
只是我的2C。
编辑：更重要的两个方面：
无国籍是一种误导。它是关于RESTfulAPI的，而不是应用程序或系统。系统需要有状态。RESTful设计是基于无状态API设计一个有状态的系统。一些来自另一个QA的引用：
- REST在资源表示上操作，每个表示都由一个URL标识。这些通常不是数据对象，而是复杂的对象抽象。
- REST代表"代表性状态转移"，这意味着它完全是关于系统中某些资源的状态的通信和修改。
等幂：其余的一个经常被忽视的部分是大多数动词的等幂。这就导致了强大的系统和对语义精确解释的依赖性降低。
这是令人惊讶的漫长的"讨论"，但至少可以说是相当混乱。
国际海事组织：
1)没有一个大的关节和大量的啤酒，就没有一个安静的程序。)
2)代表性状态转移(REST)是罗伊·菲尔丁(Roy Fielding)论文中规定的一种建筑风格。它有许多约束条件。如果您的服务/客户尊重这些，那么它就是休息的。就是这样。
您可以总结(显著)以下限制：
- 无状态通信
- 遵守HTTP规范(如果使用HTTP)
- 明确传达传输的内容格式
- 使用超媒体作为应用程序状态引擎
还有一篇很好的文章能很好地解释问题。
很多答案都是复制/粘贴有效的信息，混合在一起，增加了一些混乱。这里人们谈论的是级别，关于RESTful URI(没有这样的事情！)，应用http方法get，post，put…休息不只是为了这个，也不只是为了那个。
例如，链接——拥有一个漂亮的API是很好的，但最终客户机/服务器并不真正关心你得到/发送的链接，重要的是内容。
最后，只要内容格式已知，任何RESTful客户机都应该能够使用到任何RESTful服务。
rest==http类比在强调它"必须"是hateoas驱动之前是不正确的。
罗伊自己在这里清除了。
除了初始的URI(书签)和一组适用于预期访问群体的标准化媒体类型(即任何可能使用该API的客户机都应该理解)之外，不应在事先知情的情况下输入REST API。从那时起，所有应用程序状态转换都必须由客户机选择服务器提供的选项驱动，这些选项存在于接收的表示中，或者由用户对这些表示的操作所隐含。转换可以由客户对媒体类型和资源通信机制的了解来确定(或限制)，这两种机制都可以随时改进(例如，按需代码)。
[这里的失败意味着带外信息正在驱动交互而不是超文本。]
旧问题，新的回答方式。关于这个概念有很多误解。我总是努力记住：
我将RESTful编程定义为
An application is restful if it provides resources (being the combination of data + state transitions controls) in a media type the client understands
要成为一个休息的程序员，您必须尝试构建允许参与者做事情的应用程序。不仅仅是公开数据库。
只有当客户端和服务器同意资源的媒体类型表示形式时，状态转换控制才有意义。否则就无法知道什么是控件，什么不是控件，以及如何执行控件。也就是说，如果浏览器不知道HTML中的