related链接的内容与JSON API的{
"links": {
"self": "http://example.com/articles",
"next": "http://example.com/articles?page[offset]=2",
"last": "http://example.com/articles?page[offset]=10"
},
"data": [{
"type": "articles",
"id": "1",
"attributes": {
"title": "JSON API paints my bikeshed!"
},
"relationships": {
"author": {
"links": {
"self": "http://example.com/articles/1/relationships/author",
"related": "http://example.com/articles/1/author"
},
"data": { "type": "people", "id": "9" }
},
"comments": {
"links": {
"self": "http://example.com/articles/1/relationships/comments",
"related": "http://example.com/articles/1/comments"
},
"data": [
{ "type": "comments", "id": "5" },
{ "type": "comments", "id": "12" }
]
}
},
"links": {
"self": "http://example.com/articles/1"
}
}],
"included": [{
"type": "people",
"id": "9",
"attributes": {
"first-name": "Dan",
"last-name": "Gebhardt",
"twitter": "dgeb"
},
"links": {
"self": "http://example.com/people/9"
}
}, {
"type": "comments",
"id": "5",
"attributes": {
"body": "First!"
},
"relationships": {
"author": {
"data": { "type": "people", "id": "2" }
}
},
"links": {
"self": "http://example.com/comments/5"
}
}, {
"type": "comments",
"id": "12",
"attributes": {
"body": "I like XML better"
},
"relationships": {
"author": {
"data": { "type": "people", "id": "9" }
}
},
"links": {
"self": "http://example.com/comments/12"
}
}]
}
链接有什么区别？
答案 0 :(得分：2)
我很难找到一个直截了当的，可读的答案来回答我实际上回复的内容。
对于JSON API的示例，他们有以下JSON：
"self": "http://example.com/articles/1/relationships/author"这一行：
"self": "http://example.com/articles/1/relationships/comments"
是“关系链接”
这一行：
related
也是“关系链接”
是的，我知道这很令人困惑，因为另一个被称为GET /articles/1/relationships/comments。这些链接的目的是什么？目的是仅管理关系。所以说你做{
"data": [{
"type": "comments",
"id": "13"
}, {
"type": "comments",
"id": "29"
}],
"links": {
"self": "http://example.com/articles/1/relationships/comments",
"next": "http://example.com/articles/1/relationships/comments?page[offset]=2",
"last": "http://example.com/articles/1/relationships/comments?page[offset]=4"
},
"meta": {
"copyright": "Copyright 2015 Example Corp.",
"authors": [
"Zach Aysan"
]}
}
你做而不是返回评论的信息。您仅返回一组资源类型/ ID以及其他一些内容，例如元数据和链接。例如：
DELETE /articles/1/relationships/author为什么这有用？因为有时我们想只是删除关系，而不是资源（评论，作者）本身。因此，例如，如果我们执行了不会从users表中删除用户的PATCH /articles/1/relationships/comments，那么它只会将该用户删除为作者。要仅删除一些评论，我们会执行/articles/1/author，并且只包含我们要保留的评论。但请记住，如果后端认为这是正确的做法，后端可能会删除实际的评论。 （因为没有相关文章的评论有什么好处？）
另一个链接怎么样？为什么/people/9代替GET /articles/1/author？由于文章的作者可能会在请求之间更改，PATCH /articles/1/author将始终返回当前作者。这就是为什么我们通常不需要支持像PATCH /people/9这样的东西，因为它通常更有意义/更安全地指导资源本身的变化。 PATCH，例如，如果有人在编辑文章页面上更改了他们的头像。即使管理员更改了<nav class="navbar navbar-default">
<div >
<div class="collapse navbar-collapse">
<ul class="nav navbar-nav">
<li ui-sref-active="active"><a ui-sref="app.dit">DIT</a></li>
<li ui-sref-active="active"><a ui-sref="app.st">ST</a>
<li ui-sref-active="active"><a ui-sref="app.uat">UAT</a></li>
<li ui-sref-active="active"><a>PROD</a></li>
</ul>
</div>
</div>
</nav>
仍然使用正确资源的文章的作者身份。
我知道。这一切都有点单调乏味，但是一旦了解了所有内容，像Ember Data这样的东西就应该紧密结合在一起。