JSON表示中的链接关系
我正在devise一个基于JSON表示的RESTful API。 为了遵守HATEOAS，我广泛地利用资源之间的联系。 因此，我按照与ATOM链接非常相似的方式来遵循这个序列化链接的build议 。
现在我有时会遇到问题，找出正确的链接关系types。 当一个资源包含一个自己的链接时， self关系是显而易见的。 当资源是子资源的集合和聚合，或者包含许多到相关资源的链接时，它变得更加复杂。
以博客文章为例，并考虑一个返回博客文章快照的资源 – 包括本文的作者，标签和评论。 显然，这个资源包含许多子资源，当然也应该提供单独的链接：
示例资源：
{ "blogpost":{ "link":{ "rel":"self", "href":"http://blog/post/4711" }, "author":{ "name":"Bob", "link":{ "rel":"???", "href":"http://author/uri" } }, "title":"foobar", "content":"A long article here…", "comments":[ { "comment":"great article", "link":{ "rel":"???", "href":"http://blog/post/4711/comment/1" }, "author":{ "name":"John Doe", "link":{ "rel":"???", "href":"http://author/uri" } } } ], "tags":[ { "value":"foo", "link":{ "rel":"???", "href":"http://blog/post/4711/tag/foo" } } ] } }
那么对于给定的链接什么是适当的关系？ 我知道有tag这样的关系types，但并不是所有的资源都与现有的关系types相匹配。 或者，当引用author / tag / comment时，可以使用self ，因为它涉及到封闭的JSON（子）对象的上下文吗？ self所指的是什么语义实体？
RFC 5988指出：
链接的上下文是一个feed IRI或一个条目ID，取决于它的出现位置
我怎么能解释这个在JSON方面？ 每个新的对象{…}是一个新的上下文吗？
谢谢！
这是一个很好的问题。 如果你看一下Hal的例子，你会看到rels是在子资源的上下文中定义的。
我不知道什么时候rel与整个资源或一个被包含的子资源有关的明确指南。
我可以指出的唯一额外信息是RFC5988中的锚参数，它允许您使用片段或全新的URI重新定义上下文IRI。
理想情况下，您的媒体types应该说明上下文IRI对于嵌套资源是否不同，或者上下文IRI是否需要显式更改。 这是使用像application / vnd.hal + json这样的媒体types而不是普通的旧应用程序/ json的另一个优点，就像Hal规范所说：
@rel – 用于标识目标URI如何与“主题资源”相关联。 主题资源是最接近的父资源元素。
LSON-LD
你也许可以看一下JSON-LD （ 关联数据的 JavaScript对象表示法），它看起来比HAL更为复杂，但是你可以用它来做更多的事情。
JSON-LD正在W3C内部进行标准化， 这里是提案的build议 。
也
- HAL vs JSON-LD （由JSON-LD的创build者Manu Sporny回答）
- JSON-LD 文章和演示文稿
- 九头蛇 （ 控制台 ）
对不起，我没有时间提供一个例子..
回答这个问题有点晚了，但为了将来的参考，这是我解决这个问题的方法：
{ "blogpost":{ "title":"foobar", "content":"A long article here…", "link":{ "rel":"self", "href":"http://blog/post/4711" }, "link":{ "rel": "author", "href": "http://author/uri", "alt":"Bob" }, "link":{ "rel": "comment", "alt": "great article", "href":"http://blog/post/4711/comment/1" }, "link": { "rel":"tag", "href":"http://blog/post/4711/tag/foo", "alt":"foo" } } }
当你想到它，评论，标签等都是不同的资源链接到您的post…为什么不把他们所有的东西..链接！ 你甚至可以节省你的回复的大小;）
