具有相同 rel 的链接的 HAL+JSON 表示答案

【问题标题】：HAL+JSON representation for links with the same rel具有相同 rel 的链接的 HAL+JSON 表示
【发布时间】：2015-12-23 20:48:50
【问题描述】：

HAL 规范说：

注意：如果您不确定链接是否应该是单数，请假设将是多个。如果你选择单数并发现你需要改变它，您将需要创建一个新的链接关系或打破现有的客户。

与特定 rel 单数或复数的链接是否仅适用于在特定资源表示中使用该 rel，还是适用于在 中使用该 rel任何资源表示？

例如，如果我决定item rel 下的链接在某个资源 X 中应该始终是多个链接，那么该约束是否仅适用于资源 X，或者如果我碰巧使用 @ 它也适用于资源 Y 987654322@那里也有？

【问题讨论】：

标签： api rest hateoas hypermedia hal-json

【解决方案1】：

链接关系类型是独立于资源表示定义的。事实上，它们通常是独立于媒体类型定义的，因此可以跨媒体类型使用。

还要注意链接关系“项目”已经定义和标准化参见http://www.iana.org/assignments/link-relations/link-relations.xhtml

【讨论】：

我完全同意。 rel sematic 应该与所使用的表示类型无关。但我想知道 HAL+JSON 如何选择物理表示链接和 rel 的含义。如果一个 rel 最终有多个链接，而最初只有一个链接，则创建一个新 rel 的建议似乎暗示选择特定的物理表示可能需要您稍后创建一个全新的如果您不想破坏客户的关系，即使含义可能没有改变。我的解释是正确的，还是我遗漏了什么？
@VivinPaliath 在 JSON 中的数组和对象之间切换是一种痛苦。最初的 HAL 规范是针对 XML 的，这在 XML 中不是问题，因为 rel 只是链接元素的一个属性。老实说，我从来没有注意到 HAL 规范中的那一行。这是合理的指导，但如果您使用 JSON，无论是否因为对象/数组问题而与 rels 无关。
IMO 似乎是从 HAL+JSON 选择以 JSON 表示链接的方式的抽象泄漏；我认为不应该仅仅因为您最初使用{} 而不是[] 而创建一个新的rel；关系的含义没有改变，正如您所说，这在 XML 中不是问题。由于 JSON 问题，您最终会得到多余的 rel。这就是为什么我想知道在 JSON+HAL 的上下文中，rel 是否可以总是以某种方式表示，或者是否只适用于特定的资源表示。我喜欢前一个选项只是为了 API 的一致性。
我认为，如果您最终不得不从{} 更改为[]，也许最好完全创建一个新的媒体类型而不是拥有一个新的rel .理想情况下你不应该这样做，但也许这是两害相权取其轻。
@VivinPaliath 链接的 hal 格式的选择已经争论了很多次，而且肯定有优缺点。但是，选择当前格式是因为您可以很好地从 JavaScript 中访问链接。就个人而言，我总是使用解析库来访问媒体类型，因此我可以处理更多不自然的格式。但话又说回来，我也可以透明地处理对象/数组切换！