标题或实体中的 Hateoas 链接

Question

我已经看到了添加 JSON REST Hateoas 的两种主要方法，但我不确定哪种方法更标准或每种方法的优缺点。

我看到的典型方法（Atom Links）是返回的实体附加一个名为 或 的links字段_links。该字段是一个rel=<rel>和href=<href>对的数组。

但我也看到（链接标头）链接放入名为“Link”的标头值中。该链接是一个格式为 的集合<hef>; rel=<rel>。

另外，我注意到在 JAX-RS 中似乎没有添加具有完全限定的 href 的 Atom 链接，只有路径。我所说的完全合格是指包括计划和权威。在使用 Atom Links for HATEOAS 时，为 href 提供完整的 URI 是否被视为不好的做法？

Answer 1

我知道的所有 HATEOAS 格式都使用链接关系 RFC https://www.rfc-editor.org/rfc/rfc5988来抽象定义链接关系。该 rfc 描述了链接标头，这是传达链接关系的好方法。其他格式以不同的方式序列化/呈现链接。_links 可能与 HAL+JSON 格式最相关，而链接则由 Siren 和 COLLECTION+JSON 使用（也允许链接头）。

这都是一个偏好问题。很多时候，这都归结为询问您是否将链接关系视为资源的元数据或实际上是资源的一部分。有时两者兼而有之。HTML 主要将它们视为关系的一部分，并且在这方面取得了巨大的成功。将它们放在资源的响应正文中可以很容易地在浏览器中查看它们，而标头则有点难以查看。

关于 URL 是绝对的、方案相对的、根相对的、路径相对的。这又是所有偏好。我要记住的是，资源并不总是从请求中检索，因此相对路径通常是无用的。例如，将资源存储在缓存或磁盘上。绝对或方案相对 URL 更易于跨系统移植，在大多数情况下，我个人更喜欢它们而不是根或路径相对 URL。在一些有趣的场景中，您实际上可能希望 URL 是相对的，以便它们根据执行环境定位不同的目标。最近在 HAL 论坛上对此进行了有趣的讨论：https://groups.google.com/forum/#!topic/hal- discuss/_rwYvjLOT7Q