RESTful编程究竟是什么？

#1楼

这可能是它的样子。

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

POST /user
fname=John&lname=Doe&age=25

服务器响应：

200 OK
Location: /user/123

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

GET /user/123

服务器响应：

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

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

PATCH /user/123
fname=Johnny

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

PUT /user/123
fname=Johnny

#2楼

什么是REST？

REST代表Representational State Transfer。（它有时拼写为“ReST”。）它依赖于无状态，客户端 - 服务器，可缓存的通信协议 - 并且几乎在所有情况下都使用HTTP协议。

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

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

REST是RPC（远程过程调用）和Web服务（SOAP，WSDL等）机制的轻量级替代方法。稍后，我们将看到REST更简单。

尽管简单，但REST功能齐全; 在Web服务中基本上没有什么可以用RESTful架构完成的。 REST不是“标准”。例如，REST永远不会有W3C推荐。虽然有REST编程框架，但使用REST非常简单，您可以经常使用Perl，Java或C＃等语言中的标准库功能“自己动手”。

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

http://rest.elkstein.org/

#3楼

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

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

学习REST：教程

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

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

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

我认为你不应该因为没有听到Stack Overflow之外的REST而感到愚蠢......，我会处于同样的境地！关于为什么REST现在变大的另一个问题的答案可以缓解一些感受。

#4楼

什么是REST？

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

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

#5楼

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

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

REST约束如下：

客户端 - 服务器架构

因此它不适用于例如PUB / SUB套接字，它基于REQ / REP。
无国籍的沟通

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

因此，您不必一次又一次地提供相同的请求。
统一接口作为客户端和服务器之间的通用契约

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

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

REST系统由分层结构组成。每个层都包含使用下一层中组件服务的组件。因此，您可以毫不费力地添加新的图层和组件。

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

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

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

#6楼

RESTful （Representational state transfer）API编程通过遵循5种基本软件架构风格原则，以任何编程语言编写Web应用程序：

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

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

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

#7楼

我认为，在利用互联网（协议）作为无状态传输层的同时，将有状态分离为更高层是重要的。大多数其他方法混合起来。

这是处理互联网时代编程根本变化的最佳实用方法。关于根本性变化，Erik Meijer在此处进行了讨论： http ： //www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 。他将其总结为五种效果，并通过将解决方案设计为编程语言来提供解决方案。无论语言如何，解决方案也可以在平台或系统级别实现。宁静可以被视为在当前实践中非常成功的解决方案之一。

通过宁静的风格，您可以在不可靠的互联网上获取和操纵应用程序的状态。如果当前操作未能获得正确的当前状态，则需要零验证主体来帮助应用程序继续。如果它无法操纵状态，它通常会使用多个阶段的确认来保持正确。从这个意义上讲，休息本身并不是一个完整的解决方案，它需要Web应用程序堆栈其他部分的功能来支持其工作。

鉴于这一观点，其余的风格并没有真正与互联网或网络应用程序联系在一起。它是许多编程情况的基本解决方案。它也不简单，它只是使界面非常简单，并且非常好地应对其他技术。

只是我的2c。

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

无国籍状态具有误导性。它是关于宁静的API，而不是应用程序或系统。系统需要是有状态的。宁静的设计是基于无状态API设计有状态系统。来自另一个质量保证的一些引用：
- REST，对资源表示进行操作，每个表示由URL标识。这些通常不是数据对象，而是复杂的对象抽象 。
- REST代表“代表性状态转移”，这意味着它是关于在系统中传递和修改某些资源的状态 。
幂等性 ： REST中经常被忽视的部分是大多数动词的幂等性。这导致了强大的系统和对语义的精确解释的较少相互依赖性。

#8楼

REST代表Representational状态转移 。

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

REST通常用于移动应用程序，社交网站，mashup工具和自动化业务流程。 REST风格强调通过使用有限数量的操作（动词）来增强客户端和服务之间的交互。通过为资源（名词）分配他们自己独特的通用资源指标（URI）来提供灵活性。

关于休息的介绍

#9楼

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

#10楼

称为REST（Representational State Transfer）的架构风格提倡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请求份额。

这取自David M. Geary的优秀书籍Core JavaServer面子书。

#11楼

REST === HTTP类比是不正确的，直到你不强调它“必须”被HATEOAS驱动的事实。

罗伊自己在这里清除了它。

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

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

#12楼

什么是API测试？

API测试利用编程将调用发送到API并获得收益。它测试将被测段视为黑盒子。 API测试的目的是确认在协调到应用程序之前对其进行正确执行和错误处理。

REST API

REST：具象国家转移。

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

4种常用的API方法： -

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

手动测试API的步骤： -

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

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

自动化REST API的步骤

#13楼

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

来自维基百科：

在计算中，表示性状态转移（REST）是用于Web开发的体系结构样式。

#14楼

一本关于REST的好书是REST in Practice 。

必须读取是Representational State Transfer（REST）， REST API必须是超文本驱动的

有关RESTful服务的解释，请参阅Martin Fowlers文章Richardson成熟度模型（RMM）。

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

HATEOAS约束是Hypermedia作为应用程序状态引擎的首字母缩写。此原则是REST与大多数其他形式的客户端服务器系统之间的关键区别。

...

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

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

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

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

REST和版本控制通过可修改性讨论可扩展性，版本控制，可演化性等

#15楼

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

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

我将restful编程定义为

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

要成为一个宁静的程序员，您必须尝试构建允许actor执行的应用程序。不只是暴露数据库。

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

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

我的演讲的摘录是关于经常提到的理查森成熟度模型，我不相信等级，你要么是RESTful（3级），要么你不是，但我喜欢称之为它是什么每个级别在你去RESTful的路上为你做的

#16楼

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

IMO：

1）没有宁静的编程，没有大关节和大量的啤酒:)

2）具象国家转移（REST）是罗伊菲尔丁论文中规定的建筑风格。 它有许多限制。 如果您的服务/客户尊重这些，那么它就是RESTful。 就是这个。

您可以（显着地）将约束汇总到：

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

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

许多答案复制/粘贴有效信息混合它并添加一些混淆。人们在这里谈论层次，关于RESTFul URI（没有这样的东西！），应用HTTP方法GET，POST，PUT ...... REST不仅仅是关于那个问题。

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

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

#17楼

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

REST（Representational State Transfer）是一种设计架构，概述了如何设计和解决网络资源（即共享信息的节点）。通常，RESTful架构使得客户端（请求机器）和服务器（响应机器）可以请求读取，写入和更新数据，而客户端不必知道服务器如何操作以及服务器可以通过它不需要知道客户端的任何信息。好的，很酷......但是我们如何在实践中做到这一点？

最明显的要求是需要某种通用语言，以便服务器可以告诉客户端它正在尝试对请求做什么以及服务器做出响应。
但是为了找到任何给定的资源，然后告诉客户端资源在哪里，需要有一种指向资源的通用方法。这是统一资源标识符（URI）的用武之地; 它们基本上是查找资源的唯一地址。

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

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

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

#18楼

除了Richardson的成熟度模型是实际判断Restful是一个人的API的最佳方法之一之外，这在所有地方都很少被提及。更多关于它：

理查森的成熟度模型

#19楼

REST是一种基于Web标准和HTTP协议（2000年引入）的架构风格。

在基于REST的架构中，一切都是资源（用户，订单，评论）。通过基于HTTP标准方法（GET，PUT，PATCH，DELETE等）的公共接口访问资源。

在基于REST的体系结构中，您有一个REST服务器，可以访问资源。 REST客户端可以访问和修改REST资源。

每个资源都应该支持HTTP常用操作。资源由全局ID（通常是URI）标识。

REST允许资源具有不同的表示，例如文本，XML，JSON等.REST客户端可以通过HTTP协议（内容协商）请求特定表示。

HTTP方法：

PUT，GET，POST和DELETE方法通常用于基于REST的体系结构。下表给出了这些操作的说明。

GET定义了资源的读取访问权限，没有副作用。资源永远不会通过GET请求更改，例如，请求没有副作用（幂等）。
PUT创建一个新资源。它也必须是幂等的。
DELETE删除资源。这些操作是幂等的。它们可以重复而不会导致不同的结果。
POST更新现有资源或创建新资源。

#20楼

REST定义了6个架构约束，它们构成了任何Web服务 - 一个真正的RESTful API 。

统一界面
客户端服务器
无状态
可缓存
分层系统
按需代码（可选）

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

#21楼

我会说理解REST的一个重要组成部分在于端点或映射，例如/customers/{id}/balance 。

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

#22楼

REST是Web的基础架构原则。关于Web的惊人之处在于，客户端（浏览器）和服务器可以以复杂的方式进行交互，而客户端无需事先了解服务器及其承载的资源。关键的限制是服务器和客户端必须同意所使用的媒体，在网络的情况下是HTML 。

遵循REST原则的API不要求客户端了解有关API结构的任何信息。相反，服务器需要提供客户端与服务交互所需的任何信息。 HTML表单就是一个例子：服务器指定资源的位置和必填字段。 浏览器事先不知道提交信息的位置，并且事先不知道要提交哪些信息。 两种形式的信息完全由服务器提供。 （这个原则被称为HATEOAS ：超媒体作为应用程序状态的引擎。）

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

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

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

一种基础资源请求/可能返回是这样的：

请求

GET /
Accept: application/json+userdb

响应

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

我们从媒体的描述中了解到，我们可以从名为“链接”的部分找到有关相关资源的信息。这称为超媒体控件 。在这种情况下，我们可以从这样的部分告诉我们可以通过为/user发出另一个请求来找到用户列表：

请求

GET /user
Accept: application/json+userdb

响应

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"}]
}

我们可以从这个回复中说出很多。例如，我们现在知道我们可以通过POST到/user创建一个新/user ：

请求

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb{"name": "Karl","country": "Austria"
}

响应

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"}
}

我们也知道我们可以更改现有数据：

请求

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

响应

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谓词（ GET ， PUT ， POST ， DELETE等）来操纵这些资源，而我们在客户端部分所假设的唯一知识就是我们的媒体定义。

进一步阅读：

在这个页面上有很多更好的答案。
我如何向妻子解释REST 。
我如何向妻子解释REST 。
马丁福勒的想法
PayPal的API具有超媒体控件

（这个答案一直是批评错误的主题。在大多数情况下，这是一个公平的批评。我最初描述的更符合几年前我通常实施REST的时候首先写下这个，而不是它的真实含义。我修改了答案以更好地代表真正的意义。）

#23楼

这是一个编程，你的系统架构符合Roy Fielding在论文中提出的REST风格。由于这是描述网络的架构风格（或多或少），很多人对此感兴趣。

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

#24楼

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

您可以向/user/[id] URL发送DELETE请求，编辑用户，检索您发送的用户的信息，而不是使用特定的URL来删除方法（例如/user/123/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

#25楼

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

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

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

#26楼

RESTful编程是关于：

由持久性标识符标识的资源：URI是当今无处不在的标识符选择
使用一组通用动词操纵资源：HTTP方法是常见的案例 - 古老的Create ， Retrieve ， Update ， Delete变为POST ， GET ， PUT和DELETE 。但REST不仅限于HTTP，它现在只是最常用的传输方式。
为资源检索的实际表示取决于请求而不是标识符：使用Accept标头来控制是否需要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和Shared Nothing架构的体系结构重要性和性能影响的最重要技巧是避免对技术和实现细节感到困惑。专注于谁拥有资源，谁负责创建/维护它们等等。然后考虑表示，协议和技术。

#27楼

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

这里有一个相当不错的例子：

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

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

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

阅读完示例后，我可以看出为什么Ken说REST是超文本驱动的。我不确定他是对的，因为/ user / 123是一个指向资源的URI，而且我不清楚它是不是因为客户端“带外”知道它是不可靠的。

该xfront文档解释了REST和SOAP之间的区别，这也非常有用。当Fielding说，“ 那就是RPC。它会尖叫RPC。 ”，很明显RPC并不是RESTful，因此查看确切原因很有用。（SOAP是一种RPC。）

#28楼

如果我不得不将关于REST的原始论文减少到只有3个短句，我认为以下内容抓住了它的本质：

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

在那之后，很容易陷入有关改编，编码惯例和最佳实践的争论中。

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

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

#29楼

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

说你使用REST风格类似于说你建造了一个特定风格的房子：例如Tudor或Victorian。作为软件风格的REST和作为家庭风格的都铎王朝或维多利亚时代都可以通过构成它们的品质和约束来定义。例如，REST必须具有客户端服务器分离，其中消息是自描述的。都铎风格的住宅拥有重叠的山墙和屋顶，与前面的山墙陡峭搭配。您可以阅读Roy的论文，以了解构成REST的约束和质量的更多信息。

与家庭风格不同的REST在一直和实际应用中遇到了困难。这可能是故意的。将其实际实施留给设计师。因此，只要您满足创建REST系统论文中规定的约束条件，您就可以自由地执行所需的操作。

奖金：

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

#30楼

休息点是，如果我们同意使用通用语言进行基本操作（http动词），则可以配置基础结构以理解它们并对其进行适当优化，例如，通过利用缓存标头来实现缓存水平。

通过正确实施的Restful GET操作，无论信息来自服务器的数据库，服务器的内存缓存，CDN，代理缓存，浏览器缓存还是浏览器的本地存储都无关紧要。可以使用禁食的，最容易获得的最新来源。

说Rest只是从使用带动作参数的GET请求到使用可用的http动词的语法变化，使它看起来没有任何好处，纯粹是装饰性的。关键是要使用可以被链的每个部分理解和优化的语言。如果您的GET操作具有副作用的操作，则必须跳过所有HTTP缓存，否则您将得到不一致的结果。