【发布时间】：2009-07-22 09:41:21
【问题描述】：
我认为我对 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 应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型，或者定义扩展关系名称和/或启用超文本的标记现有的标准媒体类型。 ...
“超文本”的概念起着核心作用——比 URI 结构或 HTTP 动词的含义更重要。 “超文本”在其中一个 cmets 中定义：
当我 [Fielding] 说超文本时，我的意思是信息和控制的同时呈现，使得信息成为用户（或自动机）获得选择和选择动作的可供性。超媒体只是对文本意味着在媒体流中包含时间锚点的扩展；大多数研究人员已经放弃了这种区别。
超文本在浏览器上不需要是 HTML。机器在了解数据格式和关系类型后就可以跟踪链接。
我在这一点上猜测，但上面的前两点似乎表明 Foo 资源的 API 文档如下所示会导致客户端和服务器之间的紧密耦合，并且在 RESTful 系统中没有位置。
GET /foos/{id} # read a Foo
POST /foos/{id} # create a Foo
PUT /foos/{id} # update a Foo
相反，应该强制代理发现所有 Foos 的 URI，例如，通过对 /foos 发出 GET 请求。 （这些 URI 可能会遵循上面的模式，但这不是重点。）响应使用的媒体类型能够传达如何访问每个项目以及可以用它做什么，从而产生了上面的第三点.因此，API 文档应着重说明如何解释响应中包含的超文本。
此外，每次请求 Foo 资源的 URI 时，响应都包含代理发现如何继续进行所需的所有信息，例如，通过其 URI 访问关联资源和父资源，或采取行动在创建/删除资源之后。
整个系统的关键是响应由包含在媒体类型中的超文本组成，该媒体类型本身传达给代理选项以进行处理。这与浏览器为人类工作的方式没有什么不同。
但这只是我在这个特定时刻的最佳猜测。
菲尔丁在follow-up 上发帖回应批评称他的讨论过于抽象、缺乏示例且行话丰富：
其他人会尝试以更直接或更适用于当今某些实际问题的方式来解读我所写的内容。我可能不会，因为我太忙于处理下一个主题、准备会议、编写另一个标准、去某个遥远的地方旅行，或者只是做一些让我觉得我有薪水的小事。
那么，对于 REST 专家来说，有两个简单的问题，有实用的思维方式：您如何解释 Fielding 所说的内容，以及在记录/实施 REST API 时如何将其付诸实践？
编辑：这个问题是一个例子，说明如果你没有为你所谈论的内容命名，那么学习一些东西是多么困难。本例中的名称是“作为应用程序状态引擎的超媒体”（HATEOAS）。
【问题讨论】：
-
约翰，里奇只是在解释他的心态发生了变化。没有什么主观或争论的。投票保持开放 - 这是我在 SO 上看到的标记为“休息”的更好问题之一。
-
Keith，“解释思维方式的变化”是他应该在博客上做的事情，而不是 SO。
-
他不是在解释他的心态变化，而是在问他的理解是否准确。
-
优秀的总结。我从这个问题中学到的东西比从大多数答案中学到的更多。