我应该如何处理HATEOAS链接和JSON中的引用？ [英] How should I handle HATEOAS links and references in JSON?

问题描述

我正在设计一个REST api，并且像REST一样具有REST风格。我想将 HATEOAS 并入json回复。

向相关资源添加URL很简单，但有一些讨论用于这些链接的结构。

我发现使用一些文章从 ATOM Feed中借用的结构：

 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 use this）* / 
  friends：{href：http://example.org/entity/1/friends，type：...} 
    




• 是否有一个常见的json结构（再次适配原子） 描述资源属性中的引用（例如消息的发件人）。

  
  
  

  引用应该可以再次解析为url，但是包含简单的id也是不好的类似：

   发件人：{
  id：12345，
  href ：resource-uri
  } 
    

<我的想法是，虽然HATEOAS使得客户不需要很多知识来使用API​​，但我不愿意删除使用该知识的可能性（如通过构建访问配置文件图片）

解决方案

我在API-Craft google group上重新启动了这个主题，有一些很棒的回应。

Array设计的主要优点是：

• 相同关系的多个链接


• 同一链接的多个关系，无需编写链接aggain


• 订购链接的能力

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

就结构而言，很多可能性：

• 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。

I'm in the process of designing a REST api and to be as RESTful as it gets. I want to incorporate HATEOAS into the json responses.

Adding URLs to related resources is easy enough, but there was some discussion over the structure to use for those links.

A LOT of articles I found use a structure borrowed from ATOM feeds:

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

This raised some questions:

• Why use an array as a container? According to a javascript developer I know, access to the links would be easier with the links as properties of an object. For example:

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

• Is there a common json structure (beside adapting atom again) to describe references in resource properties? (for example the sender of a message).

  The reference should probably be resolved as a url again, but would it be bad to include the simple id as well? kind of like:

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

My way of thought is that while HATEOAS makes it so a client doesn't need a lot of knowledge to use an API, I'm kind of reluctant to remove the possibility to USE that knowledge (like accessing the profile picture by building the link client-side without looking up the user first).

解决方案

I restarted this topic on the API-Craft google group and got some great responses.

The main advantages of the Array design are:

• multiple links for the same relationship
• multiple relationships for the same link without writing the link aggain
• the ability to order the links

The map of cause has better accessibility.

As far as structure goes there are a lot of possibilities:

• JSON-HAL: http://blog.stateless.co/post/13296666138/json-linking-with-hal or also http://stateless.co/hal_specification.html
• JSON-LD: http://json-ld.org/ (optionally using Hydra vocabulary)
• JSON-Schema: http://json-schema.org/ (theHyper Meta-Schema on the bottom of the page)
• Collection+JSON: http://amundsen.com/media-types/collection/

I guess i will go with HAL as it is the cleanest solution, the rest all look kind of... strange for json.

这篇关于我应该如何处理HATEOAS链接和JSON中的引用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！