Hateoas链接在Header或Entity中

时间:2014-11-19 17:19:12

标签: json rest jax-rs hateoas

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

我看到的典型方法(Atom Links)是返回的实体附加了一个名为“links”或“_links”的字段。该字段是rel =和href = pairs的数组。

但我也看到(链接标题)链接放入名为“链接”的标题值。 Link是一个格式为“; rel =”。

的集合

另外,我注意到在JAX-RS中似乎没有添加具有完全限定href的Atom链接,只有路径。完全合格的我指的是计划和权限。在为HATEOAS使用Atom链接时,为href提供完整的URI是不是很糟糕?

谢谢!

1 个答案:

答案 0 :(得分:3)

我所知道的所有HATEOAS格式都使用链接关系RFC https://tools.ietf.org/html/rfc5988来抽象地定义链接关系。此rfc描述了链接头,这是传达链接关系的好方法。其他格式以不同方式序列化/呈现链接。 _links可能与HAL + JSON格式最相关,而Siren和COLLECTION + JSON(也允许链接头)使用链接。

这完全是一个偏好问题。很多时候,它归结为询问您是否将链接关系视为资源的元数据或实际上是资源的一部分。有时它们都是。 HTML主要将它们视为关系的一部分,并且在此过程中取得了巨大的成功。将它们放在资源的响应主体中使得在浏览器中看到它们变得非常容易,标题看起来有点棘手。

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