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＃等语言中的标准库功能“自己动手”。
当我试图找到休息的简单真实含义时，我发现了最好的参考之一。
#3楼
我想说RESTful编程将是关于创建遵循REST架构风格的系统（API）。
我找到了M. Elkstein博士关于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年我们终于被天网终止了。 直到那时 ... ;-）