rest - HATEOAS 与 PUT/POST 链接

Question

POST代表资源上//的PUTHATEOAS链接的最佳方式是PATCH什么？这些操作具有有效负载，但我们无法选择在 HATEOAS 链接中表示有效负载，因为它们不是预先确定的并且可能很重。那么仅指定终点并指定操作就足够了吗？

POST对于带有 HATEOAS //链接的 JSON 响应，任何示例或示例将不胜感激PUT。PATCH

Answer 1

链接由两个元素组成：href和rel。包含用于定位资源的href显式 URL。rel标识当前资源和链接资源之间的关系。rel应用于确定可接受的 HTTP 方法以及应如何使用链接。

以下是RESTful Web Services Cookbook第 5.4 节的引述：

链接关系类型传达了链接的角色或目的。一旦客户端和服务器就这些类型的含义达成一致，客户端就可以从链接中找到并使用 URI。

例如，edit是一个标准链接关系，它具有明确的详细信息，包括使用GET、PUT、POST、的详细信息DELETE。

链接关系可以扩展，您可以添加自己的。

Answer 2

这些操作有有效载荷，但我们没有选项来表示 HATEOAS 链接中的有效载荷，因为它们不是预先确定的并且可能很重？

通常的答案是，您在用于表示的媒体类型的描述中记录操作。

要考虑的一个参考是Atom Syndication / Atom Pub。基本思想是媒体类型的规范告诉您如何解释文档，包括对链接关系的解释。

另见菲尔丁，2008

REST API 应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型，或定义扩展关系名称和/或现有标准媒体类型的超文本启用标记。描述在感兴趣的 URI 上使用哪些方法所花费的任何努力都应该完全在媒体类型的处理规则范围内定义

通常，PUT 和 PATCH 应该非常简单——这些是远程创作方法；PUT 的请求正文通常只是 GET 提供的表示的编辑版本，而 PATCH 只是描述编辑的另一种方式（通常使用Accept-Patch标头描述的媒体类型之一）。

POST 是最难的——因为 POST 语义有非常松散的约束，有很多自由度。如果您不能直接描述附加约束，那么您必须更加依赖您对媒体类型的定义。