批量编辑含授权与未授权/不存在记录时，应返回何种HTTP状态码？

针对你遇到的批量更新混合场景，核心要先明确API的设计策略：是严格要求全量成功（只要有错误就回滚所有操作），还是允许部分成功（能更的更，不能更的返回错误），两种策略对应不同的状态码选择：

1. 全量成功/失败策略（快速失败） #

这种模式下，只要有一条记录无法处理（不存在/无权限），就不执行任何更新，返回对应状态码并在响应体中明确错误细节：

• 若存在无权限的记录：优先返回403 Forbidden，响应体列出无权限的ID列表
• 若存在不存在的记录：返回404 Not Found，响应体列出不存在的ID列表
• 混合场景（既有无权限又有不存在的记录）：返回400 Bad Request，响应体分别标注每个ID的错误类型（比如{"errors": [{"id": "1", "reason": "无权限"}, {"id": "2", "reason": "记录不存在"}]}）

2. 部分成功策略（允许部分更新） #

这种模式下，API会处理所有能正常更新的记录，同时返回无法处理的记录的错误信息，此时207 Multi-Status是标准且合适的选择——它就是为批量操作中部分成功的场景设计的。

响应体需要结构化展示每个ID的处理结果，示例格式：

{
  "batch_results": [
    {"record_id": "1", "status": 200, "result": "更新成功"},
    {"record_id": "2", "status": 404, "error": "记录不存在"},
    {"record_id": "3", "status": 403, "error": "无权限更新该记录"}
  ]
}

关键实践建议 #

• 无论哪种策略，响应体必须包含具体的错误明细，不能只返回状态码，否则调用方无法定位具体问题
• 不要纠结于“状态码是否完美匹配”，REST的核心是用状态码传递通用语义，响应体补充细节；207的适用性比你之前认为的更广，是批量操作部分成功的标准选择
• 如果API面向内部调用，可优先选择部分成功策略提升灵活性；如果面向外部用户，可根据业务需求选择快速失败（避免用户误以为全部成功）

内容的提问来源于stack exchange，提问作者David Zábranský