REST==HTTP类比是不正确的，除非你不强调它“必须”是HATEOAS驱动的。

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

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

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

REST定义了6个体系结构约束，使任何web服务都成为真正的RESTful API。

统一接口客户端-服务器无国籍的可缓存的分层系统按需编码（可选）

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

如果我不得不将关于REST的原始论文缩减为短短的3句话，我认为以下内容抓住了它的精髓：

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

之后，很容易陷入关于适应、编码约定和最佳实践的争论。

有趣的是，本文中没有提到HTTPPOST、GET、DELETE或PUT操作。这一定是后来有人对“统一界面”的“最佳实践”的解释。

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

REST==HTTP类比是不正确的，除非你不强调它“必须”是HATEOAS驱动的。

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

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

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

一本关于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架构。菲尔丁的论文规定了如果一个人想让机器彼此交谈而不是简单地通信，那么他必须遵循的体系结构。