假设我们有几种资源,它们可以单独存在,也可以按树状结构组织。为方便起见,我称它们为根,树枝和树叶。现在我想检索叶子的数据:
GET /leaf/1
Accept: application/vnd.api+json
,必须给我这样的回复
{
"data": [{
"type": "leaf",
"id": "1",
"title": "Leaf 1",
"links": {
"self": "http://example.com/leaf/1",
"branch": {
"self": "http://example.com/leaf/1/links/branch",
"related": "http://example.com/leaf/1/branch",
"linkage": { "type": "branch", "id": "5" }
},
"root": {
"self": "http://example.com/leaf/1/links/root",
"related": "http://example.com/leaf/1/root",
"linkage": { "type": "root", "id": "7" }
}
}
}],
"included": [{
"type": "branch",
"id": "5",
"title": "Branch 5",
"links": {
"self": "http://example.com/branch/5"
}
}, {
"type": "root",
"id": "7",
"title": "Root 7",
"links": {
"self": "http://example.com/root/7"
}
}]
}
从响应数据我不能说数据是分层的,它似乎适合change叶子的根目录:
PATCH /leaf/1
Content-Type: application/vnd.api+json
{
"data": {
"type": "leaf",
"id": 1,
"links": {
"root": {
"linkage": { "type": "root", "id": "3"}
}
}
}
}
这当然是不可能的,因为这个叶子连接到分支,然后只连接到根,并且更改下面模式中的根需要具有该根分支的id。问题是:
答案 0 :(得分:0)
您的示例的问题在于您将数据视为叶子和分支,而不是单独的对象。
REST是关于管理实体的。尝试将REST URL视为实体的名称。不是一些奇特的树指针。
所以,在你的情况下,像这样的PATCHing叶子是不可能的。要更改实体,您必须使用与创建实体相同的路径。
答案 1 :(得分:0)
我知道这个答案已经很晚了,但我将来会把它留给其他人。
我认为要走的路是取代"分支"和" root"与单身父母的关系"指向父节点的关系(当然是在某个根下的分支上)。然后,可以将父关系修补到任何其他节点,而不会引入不一致(因为这是之前有人修补root而不是分支的问题)。
然后,如果您仍然希望公开根节点,而不仅仅是直接父节点,您可以将此信息放在meta
某处,您可以添加一个" root"关系但不能使它可写(即,PATCH尝试将返回400/403)等等。