REST接口：使用POST/PUT批量创建更新资源的可行性及异常处理问询

1. 是否可以用POST/PUT处理多条资源？ #

REST规范没有强制要求必须只处理单个资源对象，批量操作是完全可行的，很多生产级API都会支持这种场景：

• POST批量创建：比如你提到的POST /cars，请求体直接传资源数组（注意你的示例请求体写法冗余，应该是[ {id:"car1"}, {id:"car2"}, {id:"car3"} ]，不需要外层对象包裹），用来一次性创建多个汽车资源。
• PUT批量更新：同样可行，比如PUT /cars传带唯一标识（id）的资源列表，服务端根据id匹配对应资源完成批量更新。

2. 批量操作的异常场景处理 #

批量处理时难免遇到部分条目失败的情况，常见的处理策略有三种：

• 全量回滚：只要有一个条目验证失败、资源不存在或其他错误，整个批量操作全部撤销。返回状态码400 Bad Request或500 Internal Server Error，同时在响应体里明确说明失败的具体原因（比如"error": "car2的id已存在，批量创建终止"）。
• 部分成功（推荐）：成功的条目正常生效，失败的条目单独返回错误详情。这种情况建议用状态码207 Multi-Status，响应体区分成功和失败集合，示例如下：

{
  "success": [
    {"id": "car1", "status": "已创建"},
    {"id": "car3", "status": "已创建"}
  ],
  "failed": [
    {"id": "car2", "error": "id已存在", "code": 409}
  ]
}

• 跳过失败条目：静默跳过失败的条目，只返回成功的结果。这种方式要谨慎使用，必须在接口文档里明确告知行为，避免用户误以为所有条目都已处理。

3. PUT端点批量更新的可行性 #

完全可行，但要遵守PUT的幂等性原则：重复提交相同的批量更新请求，最终得到的资源状态必须一致。比如多次提交同一批更新条目，不会导致资源被重复修改或出现不一致状态。

另外，批量PUT的请求体里，每个资源条目必须包含唯一标识（比如id），方便服务端定位到要更新的具体资源；如果某个条目对应的id不存在，服务端可以选择返回错误（纳入失败集合），或者根据业务需求自动创建该资源（这种情况要提前在文档说明）。

内容的提问来源于stack exchange，提问作者pingpong2020