我已经看到了添加 JSON REST Hateoas 的两种主要方法，但我不确定哪种方法更标准或每种方法的优缺点。
我看到的典型方法（Atom 链接）是返回的实体附加一个名为links 或_links 的字段。该字段是 rel=<rel> 和 href=<href> 对的数组。
但我也看到（链接标头）链接放入名为“链接”的标头值中。 Link 是一个集合，格式为<hef>; rel=<rel>。
另外，我注意到在 JAX-RS 中似乎没有添加具有完全限定的 href 的 Atom 链接，只有路径。我所说的完全合格的意思是包括计划和权威。在将 Atom 链接用于 HATEOAS 时，为 href 提供完整的 URI 是否被视为不好的做法？
【问题讨论】：
我知道的所有 HATEOAS 格式都使用链接关系 RFC https://www.rfc-editor.org/rfc/rfc5988 来抽象地定义链接关系。此 rfc 描述了 Link 标头，它是传达链接关系的好方法。其他格式以不同的方式序列化/呈现链接。 _links 可能与 HAL+JSON 格式最相关，而链接由 Siren 和 COLLECTION+JSON 使用（也允许链接头）。
这完全取决于偏好。很多时候归结为询问您是否将链接关系视为资源的元数据或实际上是资源的一部分。有时两者兼而有之。 HTML 主要将它们视为关系的一部分，并且在这方面取得了巨大的成功。将它们放在资源的响应正文中可以很容易地在浏览器中查看它们，而标头则有点难以查看。
关于 URL 是绝对的、方案相对的、根相对的、路径相对的。这又是所有偏好。我想记住的是，资源并不总是从请求中检索到，因此相对路径通常是无用的。例如，将资源存储在缓存或磁盘上。绝对或方案相对 URL 在系统之间更易于移植，在大多数情况下，我个人更喜欢它们而不是根或路径相对 URL。在一些有趣的场景中，您可能实际上希望 URL 是相对的，以便它们根据执行环境定位不同的目标。最近在 HAL 论坛上有一个有趣的讨论：https://groups.google.com/forum/#!topic/hal-discuss/_rwYvjLOT7Q
【讨论】：