我会说，RESTful编程是关于创建遵循REST体系结构风格的系统（API）。

我发现M.Elkstein博士的这篇关于REST的精彩、简短且易于理解的教程，并引用了最能回答您问题的重要部分：

学习REST：教程

REST是一种用于设计网络应用程序的架构风格。其思想是，使用RPC或SOAP连接机器，使用简单的HTTP机器之间的呼叫。在许多方面，基于HTTP的万维网本身可以被视为基于REST的架构。RESTful应用程序使用HTTP请求来发布数据（创建和/或更新）、读取数据（例如进行查询）和删除数据。因此，REST对所有四个CRUD（创建/读取/更新/删除）操作使用HTTP。

我认为你不应该因为没有听到堆栈溢出之外的REST而感到愚蠢。。。，我也会遇到同样的情况！；另一个SO问题“为什么REST现在变得越来越大”的答案可能会缓解一些情绪。

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

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

一本关于REST的好书是《实践中的REST》。

必须读取代表性状态传输（REST），并且REST API必须是超文本驱动的

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

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

HATEOAS约束是首字母缩略词超级媒体的引擎应用程序状态。这一原则是REST之间的关键区别以及大多数其他形式的客户端服务器系统...RESTful应用程序的客户端需要只知道要访问的单个固定URL所有未来的行动都应该可从中动态发现超媒体链接包含在资源的表示从该URL返回。标准化媒体类型也是预期任何人都能理解可能使用RESTful API的客户端。（来自免费百科全书维基百科）

Web框架的REST Litmus测试是Web框架的类似成熟度测试。

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

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

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

交谈不仅仅是交换信息。协议实际上是这样设计的，因此不必进行对话。每一方都知道他们的具体工作是什么，因为它在协议中有所规定。协议允许纯粹的信息交换，而不需要对可能的操作进行任何更改。另一方面，谈话允许一方询问另一方可以采取什么进一步行动。他们甚至可以问同一个问题两次，并得到两个不同的答案，因为另一方的状态可能在这期间发生了变化。对话是RESTful架构。菲尔丁的论文规定了如果一个人想让机器彼此交谈而不是简单地通信，那么他必须遵循的体系结构。

什么是REST？

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

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