RESTful HATEOAS 客户端网址

Question

我有理由相信我了解 HATEOAS 设计的服务器端 - 在响应中返回状态 URL - 但我对如何设计客户端来接受这些感到有点困惑。

例如，我们在//somehost.com/resource/1 访问资源 - 这为我们提供了资源数据和链接。我们假设返回 POST 到//somehost.com/resource，表示一个"new"操作。现在我知道将一些数据发布到该 url 会创建一个新资源并提供响应，但是发布该数据的表单位于何处？我已经看到实现，其中//somehost.com/resource/1/new 提供了一个 POSTS 到/resource 的表单，但是该 URL 本身包含一个动词，并且似乎违反了 REST。

我认为我的困惑在于我在同一个应用程序中实现了一个 RESTful API 和一个客户端来使用它。

对于这类事情是否有某种最佳实践？

Answer 1

I've seen implementations where //somehost.com/resource/1/new provides a form which POSTS to /resource, but that URL itself contains a verb, and seems to violate REST.

这是不正确的。 包含动词的 URI 本身不违反任何 REST 约束。只有当该 URI 代表一个 Action 时，这才成为违规行为。如果您可以对 URL 执行 GET 请求并接收到一些有意义的资源(例如“创建新资源”表单)，那么这完全是 REST 风格的，也是很好的做法。

我自己的 API 与您描述的完全一样:/{collection}/new 返回一个表单。 /new只是一个假设的/new-resource-creation-form的简写，仍然代表一个名词，只支持GET请求(不支持HEAD、OPTIONS和TRACE) .
HATEOAS 禁止的是要求用户代理知道，为了创建新资源，它必须将 /new 添加到集合的名称中。

基本上，如果您将 API 实现为 (X)HTML，并且可以 surf it in a browser并执行所有操作(非 POST 表单提交可能需要 AJAX，直到 HTML 和浏览器 catch HTTP)，然后它符合 REST 的超媒体约束。

编辑 从评论中推广:

只要响应否定对先验知识的任何需求，它就符合超媒体约束。如果客户端声称理解 HTML，并且您发回包含指向外部样式表或 javascript(无论托管在何处)的链接的响应，客户端需要能够正确呈现页面，那么可以合理地说约束得到满足。客户端应该知道如何处理它声称支持的所有媒体类型。普通的人类 Web 浏览器是客户端对任何 HTTP 服务(网站)没有带外知识的完美示例。

明确地说，网站是一种 HTTP 服务。 Web 浏览器不会区别对待不同的网站。为了在亚马逊上搜索产品，您在 http://amazon.com/ 加载亚马逊服务端点并点击链接或填写该响应中提供的表格。为了在 eBay 上搜索产品，您在 http://ebay.com/ 加载 eBay 服务端点并执行相同的操作。
浏览器事先并不知道要搜索 eBay 你必须做这个，但是要搜索 Amazon 你必须做那个。浏览器是无知的。其他 HTTP 服务的客户端也应该是无知的。