请求信息正确但不足时适用的HTTP错误码咨询

针对你提到的场景——客户端提交的信息格式正确但缺少必要上下文/信息，需要补充后才能处理请求——以下是各候选状态码的分析和落地建议：

排除412与428的原因 #

• 412 Precondition Failed：该状态码仅适用于请求头中前置条件校验失败的场景（比如If-Match、If-None-Match这类条件请求头不满足要求），和业务层面的信息缺失完全不相关，属于典型的误用场景。
• 428 Precondition Required：同样与请求头强绑定，作用是强制客户端发送指定的前置条件头才能发起有效请求，本质是约束请求机制，而非处理业务信息不足的问题，因此也不适用。

优先选用422 Unprocessable Entity #

422 Unprocessable Entity是当前场景下最贴合HTTP规范的选择：

• 它的标准定义是“服务器理解请求的内容类型、请求语法也正确，但无法处理请求中的语义内容”，完美匹配“信息格式合法但不足以完成业务处理”的情况。
• 尽管它的通用性较强，但这种通用性正好能覆盖各类业务场景下的信息缺失问题（比如提交订单缺收货地址、创建用户未填必填字段等）。
• 实际使用时，建议在响应体中明确告知需要补充的具体信息，示例如下：

  {
    "error_msg": "缺少必要业务信息",
    "required_fields": ["shipping_address", "contact_phone"]
  }
  

补充提示 #

如果你的API有自定义业务错误码体系，可以在422响应中附带更细致的业务标识，但HTTP状态码层面，422是最合规的选择。

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