在RESTful API开发中，正确选择HTTP状态码不仅是技术规范的要求，更是提升接口可维护性和开发者体验的关键。近期，关于“HTTP 400 Bad Request”与“HTTP 422 Unprocessable Entity”在API验证场景下的区分问题，再次引发技术社区的广泛讨论。本文将从协议定义、语义差异、实际应用场景三个维度，为开发者厘清二者之间的核心差异。

协议出身：官方定义与历史渊源

HTTP 400状态码在RFC 7231中被定义为“Bad Request”，意指服务器无法理解客户端发送的请求，通常是由于请求语法错误、参数格式错误或缺少必要头信息。它属于4xx客户端错误大类，是Web应用中最常见的“万能错误码”。

HTTP 422状态码则来源于WebDAV扩展规范（RFC 4918），最初是为支持分布式创作和版本控制而引入。它被定义为“Unprocessable Entity”，表示服务器理解请求的语法，但无法处理包含的语义内容。例如，JSON结构正确但字段值不满足业务规则（如年龄为负数）。在REST API实践中，422逐渐被广泛采用，以区分“格式错误”与“内容违规”。

核心差异：语法错误 vs. 语义错误

理解二者区别的关键在于分清“语法”与“语义”两个层面。

  • HTTP 400适用于语法层级的错误：当请求体不是合法的JSON格式、缺少必须的请求头部、参数类型不匹配（如字符串传给数字字段）时，返回400。这类错误意味着请求本身在“机械层面”就是不合理的，服务器甚至无法正确解析它。

  • HTTP 422适用于语义层级的错误：请求体是合法的JSON，语法完全正确，但其中的数据不满足业务规则。例如，用户注册接口要求“年龄在0-120之间”，但传入“年龄：150”；或者要求“邮箱符合格式”，但传入的邮箱是“abc”。此时服务器能解析请求，但无法执行业务逻辑。

实战场景：如何选择

以典型的用户注册API为例：
1. 如果客户端发送的JSON中是“age：abc”，类型错误导致解析失败 → 应返回400，并提示“字段age必须是数字”。
2. 如果JSON中“age：-5”，语法正确（数字类型），但不符合业务规则 → 应返回422，并提示“年龄不能为负数”。
3. 如果请求缺少“Authorization”头，服务器无法进行身份验证 → 返回400（或401，取决于具体语义）。
4. 如果请求体的字段名拼写错误，如“emial”而非“email”，导致服务端映射失败 → 不同框架处理不一，但推荐返回400，因为字段缺失属于结构性问题。

需要注意的是，并非所有API设计都严格遵循这一划分。一些团队将所有验证错误统一返回400，虽然简单但会模糊错误类型，增加客户端调用的调试成本。而过度使用422也可能导致与一些老旧客户端、代理或网关的兼容性问题，因为422并非所有HTTP库原生支持。

行业实践与最佳建议

目前主流的REST API设计规范如JSON:API、微软REST API指南等，普遍推荐以下做法：
- 对于请求结构错误（JSON解析失败、必填参数缺失、类型不匹配）→ 使用400。
- 对于请求内容违反业务逻辑（字段值不满足约束、唯一性冲突、状态转换不允许）→ 使用422。
- 对于认证授权错误（无效令牌、权限不足）→ 使用401或403，而非400或422。
- 返回错误体时，应包含清晰的错误代码、描述和字段定位信息，协助客户端快速修正。

此外，值得一提的是，GraphQL等新协议已不再依赖HTTP状态码传递语义错误，而是返回200并携带错误数据。但REST生态中，合理使用400和422仍是提升API质量的重要手段。

小结

HTTP 400和422的区别本质上是“请求格式问题”与“请求内容问题”的分界线。正确运用不仅能帮助开发者快速定位问题，还能让API的契约表述更精确。在项目初期定义统一的错误响应策略，并将此规范写入API文档，是每一位架构师和开发者的必修课。对于初学者而言，记住一个简单法则作为起点：“如果客户端换个格式重试可能会成功，就返回422；如果重试无望，就返回400。”当然，这只是一个启发式判断，最终决策还需结合实际业务场景与团队约定。