我在设计一个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结构 （再次调整原子旁边） 来描述资源属性的参考？ （例如，消息的发送者）。
参考或许应该被解析为再次URL，但它是坏的，包括简单的ID呢？ 有一些像：
"sender": { "id": 12345, "href": "resource-uri" }
我的思维方式是，虽然HATEOAS使得它如此一个客户端并不需要很多的知识使用API，我有点舍不得删除的可能性，使用知识（如通过建立链接访问资料图片客户端无需先查找用户）。
我重新启动的API-工艺谷歌组这个话题，并得到了一些伟大的反应。
该阵列设计的主要优点是：
- 对同一关系的多个链接
- 对于同一个链接倍数关系，而无需编写链接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/ （任选地使用水润词汇）
- JSON-架构： http://json-schema.org/ （在页面的底部theHyper元模式）
- 收藏+ JSON： http://amundsen.com/media-types/collection/
我想我会去HAL，因为它是最干净的解决方案外，其余全部看那种......奇怪的JSON。
至于结构的话，你可以尝试寻找HAL（ http://stateless.co/hal_specification.html ）或JSON-LD：（ http://json-ld.org/ ）
我认为它使您可以提供基于HTTP方法多个环节。
如
"links": [
{"rel": "sender", "method":"post", "href":"http://example.org/entity/1"},
{"rel": "sender", "method":"put", "href":"http://example.org/entity/1"}, ...
]
也许你能适应，为您的想法
"sender": {
"href":"http://example.org/entity/1",
"methods": ["put","post"]
}
