RESTAPI真的是RPC吗？罗伊·菲尔丁似乎也这么认为

我认为我所知道的关于REST的大量知识显然是错误的——我并不孤单。这个问题有很长的引入时间，但似乎是必要的，因为信息有点分散。如果你已经熟悉这个主题，那么实际的问题就在最后

从罗伊·菲尔丁（Roy Fielding）的第一段可以很清楚地看出，他认为自己的作品被广泛误解了：

很多人将任何基于HTTP的接口称为RESTAPI，这让我感到沮丧。今天的例子是。这就是RPC。它尖叫着。显示器上的耦合太多，所以应该给它一个X级

Fielding接着列出了RESTAPI的几个属性。其中一些似乎违背了SO和其他论坛上的常规做法和常见建议。例如：

• 输入REST API时，除了初始URI（书签）和适用于预期受众的一组标准化媒体类型（即，任何可能使用该API的客户端都应该理解）之外，不需要任何先验知识

• RESTAPI不能定义固定的资源名称或层次结构（客户端和服务器的明显耦合）

• REST API应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有标准媒体类型定义扩展关系名称和/或支持超文本的标记

“超文本”的概念起着核心作用——比URI结构或HTTP动词的含义更重要。“超文本”的定义如下：

当我（菲尔丁）说超文本时，我指的是同时呈现信息和控制，使信息成为用户（或自动机）获得选择和选择行动的启示。超媒体只是对文本含义的扩展，在媒体流中包含时间锚；大多数研究人员已经放弃了这种区分

在浏览器上，超文本不需要是HTML。当机器理解数据格式和关系类型时，它们可以跟随链接

我猜测这一点，但上面的前两点似乎表明，Foo资源的API文档（如下所示）会导致客户机和服务器之间的紧密耦合，在RESTful系统中没有一席之地

GET   /foos/{id}  # read a Foo
POST  /foos/{id}  # create a Foo
PUT   /foos/{id}  # update a Foo

相反，应该强制代理通过（例如）对/Foos发出GET请求来发现所有foo的uri。（这些URI可能会遵循上面的模式，但这不是重点。）响应使用一种媒体类型，能够传达如何访问每个项目以及可以使用它做什么，从而引出上面的第三点。因此，API文档应该重点解释如何解释响应中包含的超文本

此外，每次请求Foo资源的URI时，响应都包含代理发现如何继续操作所需的所有信息，例如，通过其URI访问关联资源和父资源，或者在创建/删除资源后采取操作

整个系统的关键在于，响应由包含在媒体类型中的超文本组成，该媒体类型本身向代理传递继续操作的选项。这和浏览器为人类工作的方式没什么不同

但这只是我在这个特殊时刻的最佳猜测

菲尔丁发表了一篇文章，回应了批评他的讨论过于抽象、缺乏示例和术语丰富的批评：

其他人会试图以更直接或更适用于当今某些实际问题的方式解读我所写的内容。我可能不会，因为我太忙于下一个话题，准备一个会议，写另一个标准，去遥远的地方旅行，或者只是做一些让我觉得自己挣钱了的小事

因此，对于具有实践思维的REST专家来说，有两个简单的问题：如何解释Fielding所说的内容，以及在记录/实现REST API时如何将其付诸实践

---

编辑：这个问题是一个例子，说明如果你所说的东西没有名字，学习起来有多难。本例中的名称是“作为应用程序状态引擎的超媒体”（HATEOAS）。

我认为您的解释主要涵盖了它。URI是不透明的标识符，在大多数情况下，除了用户代理用来访问应用程序的书签URI之外，不应该传递这些标识符

至于记录，这个问题已经做了很多次了。您可以记录媒体类型及其包含的超链接控件（链接和表单）以及交互模型（如果愿意）（请参阅AtomPub）

---

如果您记录了URI或如何构建它们，那么您就错了。

给出如何构建URI的说明的一个例外是，允许在超文本响应中发送URI模板，并使用超文本中的其他字段由客户端自动替换字段。这通常不会节省很多带宽，因为gzip压缩可以很好地处理uri的重复部分，而不必为此费心

关于REST和相关HATEOAS的一些良好讨论：

---

绝对正确。此外，我还要指出，只要模式来自从服务器接收的文档（OpenSearch就是一个合适的例子），URI模板在RESTful应用程序中就非常好。对于URI模板，可以记录它们的使用位置以及模板中预期的占位符，但不能记录模板本身。与瓦恩·弗里登所说的稍有不同，这并非例外

例如，在我的工作中，我们有一个内部域管理系统