我应该设计一个REST API,其中资源(例如todo资源)将以用户创建的顺序发送到UI。资源具有order
属性,该属性是一个整数,表示必须在UI中显示资源的索引。用户可以在UI中进行操作,用户可以对资源进行重新排序 - 将资源的MOVE
类型的order
的重新排序作为PATCH操作考虑是正确的。资源?
重新订购操作会重新安排或重新排序修改其他资源的order
值的资源列表。
根据正确的REST API设计原则,设计它的最佳方法是什么?
答案 0 :(得分:0)
从您的示例中order
只是一个属性,例如todo项目的name
或description
。
是的,PATCH可以部分更新资源。请注意,在您的情况下,您实际上并没有移动资源,只是修改了修改它在另一个资源(此todo项目列表)中的排序的属性。
听起来我们这里有2个资源:
order
属性)资源可以是可以订购的子资源列表,但您不会将URL更改为项目或列表。
例如:
/list/{list_id}/item/{item_id} ---> specific todo item resource
/list/{list_id} --> items in the todo list, ordered attribute
如果订单属性与商品绑定,那么/list/{list_id}/item/{item_id}
或/list/{list_id}
上的多个商品资源上的补丁替换就可以了,但您不会更改任何ID或URI到列表或项目,只是项目的订单。