在JSONAPI specification, under Resource Objects中,它给出了这个资源示例:
{
"type": "articles",
"id": "1",
"attributes": {
"title": "Rails is Omakase"
},
"relationships": {
"author": {
"links": {
"self": "/articles/1/relationships/author",
"related": "/articles/1/author"
},
"data": { "type": "people", "id": "9" }
}
}
}
如果我不使用资源包含,我的客户应该如何处理以下信息:
"data": { "type": "people", "id", "9" }
回复中包含指向article
作者(/articles/1/author
)的链接 - 我可以通过阅读回复的data { ... }
元素来判断文章是id=9
的人,但我实际上无法对该信息做任何有用的事情。
我可以使用此信息向/people/9
发出GET请求以检索作者详细信息,这似乎很直观,但这似乎不是JSONAPI规范的一部分(尽管有{ {3}}这些关于资源集合的URL的行
内联type/id
信息是仅与资源包含或交叉引用一些先前缓存的响应数据的上下文相关吗?或者是否有关于将type+id
翻译成资源网址(GET /{type}/{id}
)的无证公约?
答案 0 :(得分:0)
它用于交叉引用从服务器检索的其他数据。您可以在其他时间偶然加载记录person:9
,并且知道author
上的article:1
关系可以省去将GET
发送到/articles/1/relationships/author
的麻烦
例如,ember-data客户端商店会自动为您解析引用。