我正在设计一个基于 JSON 表示的 RESTful API。为了遵守 HATEOAS,我广泛使用资源之间的链接。因此,我遵循了这个建议,以与 ATOM 链接非常相似的方式对链接进行序列化。
现在我有时在识别正确的链接关系类型时遇到问题。当资源包含指向自身的链接时,这种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
,但并非我的所有资源都与现有的关系类型匹配。还是self
在引用作者/标签/评论时可以使用,因为它与封闭的 JSON(子)对象的上下文有关?语义实体self
指的是什么?
RFC 5988 指出:
链接的上下文是提要 IRI 或条目 ID,具体取决于它出现的位置
我如何用 JSON 来解释这一点?每个新对象{…}
都是一个新的上下文吗?
谢谢!