我认为我对 REST 了解的大部分内容显然是错误的——而且我并不孤单。这个问题的引文很长，但似乎很有必要，因为信息有点分散。如果您已经熟悉该主题，那么实际问题将在最后出现。
从 Roy Fielding 的REST APIs must be hypertext-driven的第一段开始，很明显他认为他的工作被广泛误解了：
我对将任何基于 HTTP 的接口称为 REST API 的人数感到沮丧。今天的例子是SocialSite REST API。那就是RPC。它尖叫 RPC。展示的耦合太多了，应该给它一个 X 评级。
Fielding 继续列出 REST API 的几个属性。其中一些似乎违背了 SO 和其他论坛上的常见做法和常见建议。例如：
除了初始 URI（书签）和适合目标受众（即，任何可能使用 API 的客户端都可以理解）的标准化媒体类型集之外，应该在没有任何先验知识的情况下输入 REST API。...
REST API 不得定义固定的资源名称或层次结构（客户端和服务器的明显耦合）。...
REST API 应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型，或定义扩展关系名称和/或现有标准媒体类型的超文本启用标记。...
“超文本”的概念起着核心作用——比 URI 结构或 HTTP 动词的含义更重要。“超文本”在评论之一中定义：
当我 [Fielding] 说超文本时，我的意思是信息和控制的同时呈现，使得信息成为用户（或自动机）获得选择和选择动作的可供性。超媒体只是对文本意味着在媒体流中包含时间锚点的扩展；大多数研究人员已经放弃了这种区别。
超文本不需要是浏览器上的 HTML。当机器了解数据格式和关系类型时，它们可以跟踪链接。
我猜到了这一点，但上面的前两点似乎表明 Foo 资源的 API 文档如下所示会导致客户端和服务器之间的紧密耦合，并且在 RESTful 系统中没有位置。
GET /foos/{id} # read a Foo
POST /foos/{id} # create a Foo
PUT /foos/{id} # update a Foo
相反，应该强制代理通过例如向 /foos 发出 GET 请求来发现所有 Foos 的 URI。（这些 URI 可能会遵循上面的模式，但这不是重点。）响应使用的媒体类型能够传达如何访问每个项目以及可以用它做什么，从而产生了上面的第三点. 出于这个原因，API 文档应该专注于解释如何解释响应中包含的超文本。
此外，每次请求 Foo 资源的 URI 时，响应都包含代理发现如何继续进行所需的所有信息，例如，通过其 URI 访问关联资源和父资源，或在创建后采取行动/删除资源。
整个系统的关键在于响应由包含在媒体类型中的超文本组成，该媒体类型本身传达给代理选项以进行处理。这与浏览器为人类工作的方式没有什么不同。
但这只是我在这个特定时刻的最佳猜测。
菲尔丁发表了一篇后续文章，回应批评称他的讨论过于抽象、缺乏示例且行话丰富：
其他人会尝试以更直接或更适用于当今某些实际问题的方式来解读我所写的内容。我可能不会，因为我太忙于处理下一个话题、准备会议、编写另一个标准、去某个遥远的地方旅行，或者只是做一些让我觉得我已经赚到了薪水的小事。
因此，对于 REST 专家来说，有两个简单的问题，有实用的思维方式：您如何解释 Fielding 所说的内容，以及在记录/实施 REST API 时如何将其付诸实践？
编辑：这个问题是一个例子，说明如果你没有为你所谈论的内容命名，那么学习一些东西会有多么困难。在这种情况下，名称是“作为应用程序状态引擎的超媒体”（HATEOAS）。