REST PUT 网址约定答案

【问题标题】：REST PUT url conventionsREST PUT 网址约定
【发布时间】：2013-01-10 15:27:03
【问题描述】：

我正在尝试找出使用 REST 约定进行更新的正确方法。到目前为止，我们有：

单个项目的更新：

PUT
https://mydomain.com/dogs/{id}    accept: application/json, {dog}

更新多个项目：

PUT
https://mydomain.com/dogs    accept: application/json, [{dog1}, {dog2}, ...]

我试图弄清楚惯例是否也规定（除了我们上面的内容之外，或者代替我们上面的内容）：

PUT
https://mydomain.com/dogs    accept: application/json, {dog}

然后，后续问题：假设我们更新集合时某个元素出现验证错误。惯例是否规定我们返回 422 并拒绝整个请求？还是我们更新有效的并返回 4xx 状态码？

【问题讨论】：

在您的第二个示例（列表）中，最好使用 POST。 POST 是“附加”动词，您将两个项目附加到狗列表中。 PUT 的意思是“这是所有狗的集合！”。 ...第三个例子的问题是你不知道狗有什么{id}！这不是狗系列的代表！所以你最好只使用 (1) 或者在 (3) 中再次使用 POST。 POST 更常见于创建。 ...如何返回验证错误完全取决于您——我不知道有明确的约定。恕我直言，我可能会拒绝整件事。

标签： rest put

【解决方案1】：

PUT 一般用于更新，但 PUT 不代表更新。 PUT 背后的基本思想是将资源放置在特定位置。您的第一个代码段是准确的，因为您将该资源的新版本放在该位置。

但是，以下两个请求不支持 PUT 的语义：

PUT
https://mydomain.com/dogs    accept: application/json, [{dog1}, {dog2}, ...]

PUT
https://mydomain.com/dogs    accept: application/json, {dog}

一般来说，我会要求那些调用我的 API 的人执行多个 PUT 请求，这些请求可以并行完成，以更新多个资源。但是，如果需要同时更新多个资源，我会考虑使用POST，例如：

POST
https://mydomain.com/dogs/update-many  accept: application/json, [{dog1}, ...]

就错误情况而言，最好通过文档处理。我认为，只要用户知道该行为，要么拒绝整个请求并回滚，要么返回包含每个已发送实体的标识符/成功状态的响应都是有效的。一般来说，我认为响应与请求直接相关，而不是与请求中的每个项目相关；因此，如果请求的任何部分失败，我会返回错误代码和解释。我觉得当假设请求的任何部分具有持久影响时，用户总是期望 2XX 代码更简单。

【讨论】：