我正在尝试找出使用 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 状态码？
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 代码更简单。