json - 我应该如何处理 JSON 中的 HATEOAS 链接和引用？

Question

我正在设计一个 REST api 并尽可能地保持 RESTful。我想合并HATEOAS进入 json 响应。

将 URL 添加到相关资源很容易，但对用于这些链接的结构进行了一些讨论。

我发现很多文章都使用从 ATOM 借来的结构。供稿:

"links": [ 
    {"rel": "self", "href":"http://example.org/entity/1"},
    {"rel": "friends", "href":"http://example.org/entity/1/friends"}, ... 
]

这引发了一些问题:

• 为什么使用数组作为容器？据我认识的一位 javascript 开发人员说，将链接作为对象的属性访问链接会更容易。例如:

  "self":    { "href":"http://example.org/entity/1" }, /* (facebook uses this) */  
  "friends": { "href":"http://example.org/entity/1/friends", "type": "..."}
  

• 是否有一个通用的 json 结构(除了再次适配 atom)来描述资源属性中的引用？(例如消息的发送者)。

  引用可能应该再次解析为 url，但是包含简单 id 会很糟糕吗？有点像:

  "sender": { 
      "id": 12345,
      "href": "resource-uri"
  }
  

我的想法是，虽然 HATEOAS 让客户不需要很多知识来使用 API，但我有点不愿意消除使用这些知识的可能性(比如通过在不首先查找用户的情况下构建链接客户端)。

Answer 1

我在 API-Craft google group 上重新启动了这个话题，并得到了一些很好的回应。

Array设计的主要优点是:

• 同一关系的多个链接
• 同一链接的多个关系，无需重新编写链接
• 能够对链接进行排序

原因 map 具有更好的可访问性。

就结构而言，有很多可能性:

• JSON-HAL:http://blog.stateless.co/post/13296666138/json-linking-with-hal或者http://stateless.co/hal_specification.html
• JSON-LD:http://json-ld.org/ (可选地使用 Hydra 词汇)
• JSON 架构:http://json-schema.org/ (页面底部的 Hyper Meta-Schema)
• 集合+JSON:http://amundsen.com/media-types/collection/

我想我会选择 HAL，因为它是最干净的解决方案，其余的看起来有点……对 json 来说很奇怪。