嵌套对象的RESTful重新排序

我有一个RESTful API，它支持两个对象，因此对象

a

包含嵌套对象的有序列表

B

：

Create object A               - POST  /a
Create object B and add to A  - POST  /a/<id>/b
Update object B in A          - PATCH /a/<id>/b/<id>

创建对象A-发布/A
创建对象B并添加到A-POST/A//B
更新A-PATCH/A//B中的对象B/

更新特定

a

中

B

对象顺序的RESTful方法是什么？

选项1:

用json内容修补/a/

，替换

a.Bs

A

有一个嵌入的

B

s列表，即

A.Bs

，因此您可以将该列表全部替换，也可以在途中更改顺序。这依赖于客户端正确地重新提交整个列表

选项2:

用json内容修补/a/

，替换

a.B_顺序

添加一个单独的

B

id列表，并让客户端对其进行更新。这与选项1类似，但不依赖于客户端重新提交所有对象。它确实需要服务器管理列表，在创建

B

时更新列表，并验证更新是否包含列表顺序更新所需的所有

B

ID

选项3:

用json内容修补/a//b

，替换

a.Bs

与选项1相同，但URL不同

哪一个最安静、最清晰？

---

还有其他选择吗？

我建议使用中定义的建议标准。具体来说，“移动”操作似乎就是您要寻找的内容。

如果Foo有条，并且条是资源（有ID或链接），当您需要重新排序Foo.bar时，我建议：

“PUT/foos/：id/bar”，主体中包含id或链接数组

但如果条不是资源（没有ID），则：

---

带有Foo主体的“PATCH/foos/：id”，包括“bar”属性中完整的新Foo.bar数组。

我想问自己的问题是：“在这种情况下，“order”是什么意思？”

B

的特定实例之间没有顺序。它们都是独立的资源，并不真正“了解”每个订单

考虑到这一点，您正在更改的并不是

B

资源。你在换什么

大概在某处有一个

B

的集合。您对该集合执行

GET

请求，以获得

B

的有序列表。你是在

/a/

上还是在

/a//b

上看到这个列表的

无论排序列表在哪里，我都会执行更改顺序的操作，因为顺序是集合的“属性”

因此，为了论证，让我们假设您的

B

集合存在于

/a/B

上。应该是什么格式

好吧，良好的休息服务将取代整个州。因此，默认情况下，我会对该资源执行

请求，并对整个资源进行完全替换

如果您不喜欢这个想法，并且希望使用
PATCH
只更新集合的一部分（而不更新其他内容），我想我会选择以下选项之一：

使用标准格式，如
json补丁
想出你自己的语法来描述这一点
选项2的实现可能会简单得多，我也会尽可能保持格式的简单

如果使用HAL格式，则集合可能是链接列表。在这种情况下，我将使用如下语法：

{
  "_links": {
     "item": [
        { "href": "/a/<id>/b/ordered-item-1" },
        { "href": "/a/<id>/b/ordered-item-2" }
      ]
  }
}

在每种情况下，最好为此定义自己的媒体类型，因为此补丁格式对api有特殊意义。例如：

application/vnd.jonathan.patch+json

顺便说一句，我使用
PATCH
进行部分更新，而不是
PUT
，后者取代了整个objectwhy not POST？@richard POST也可以用于这种情况，但是补丁比POST更具体/语义正确，因此更适合。我仍在试图找出a和常规补丁的区别，因为对我来说，它们实际上是一样的。这样，客户机不应该解释URI，而应该将它们用作指向资源的指针。与一般观念相反，URI本身不包含任何路径逻辑，应该作为一个整体使用。当然，您可以通过提供一组URI来“伪造”路径逻辑，这些URI总体上形成一个可遍历的图。HTTP允许通过补丁或PUT更新重叠资源进行部分更新。这会对实际的ResSource进行部分更新。与PUT不同，补丁实际上是一种方法，客户端可以使用它向服务器发送有关如何将当前资源修改为所需状态的分步指令。客户机实际上是在告诉服务器如何转换资源，而不是将最终输出呈现给服务器。此外，还需要成功完成所有指令，或者根本不应用任何指令，这需要操作的一些事务性要求。正如埃里克和埃弗特已经提议的那样，我也建议使用thereforenice参考资料，但至少对我来说，这似乎是一种矫枉过正的做法
application/vnd.jonathan.patch+json