我以为我对REST了解的很多知识显然是错误的-而且我并不孤单。这个问题的引入时间很长，但是由于信息有点分散，因此似乎很有必要。如果您已经熟悉此主题，那么实际问题就在最后。
从Roy Fielding的REST API的第一段开始，它必须是超文本驱动的，很明显，他认为自己的工作被广泛误解了：
人们对将任何基于HTTP的接口称为REST API的人数感到沮丧。今天的示例是SocialSite REST API。那就是RPC。它尖叫RPC。显示器上的耦合太多，因此应给定X等级。
字段继续列出了REST API的几个属性。他们中的一些人似乎与SO和其他论坛上的常规做法和常规建议背道而驰。例如：
输入REST API时，除了初始URI（书签）和适合目标受众（即，可能会使用该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）。