400和422 HTTP状态代码之间的差异

有很多讨论，如果HTTP请求负载缺少强制属性，则响应代码必须是400或422

我还不清楚其中的区别

---

请用逻辑场景/示例建议何时使用400或422 HTTP状态码。

据我所知，400用于语法错误的请求，422用于表面错误的请求。 如果你期待像这样的请求

...
  <name>test name</name>
  <date>2020-01-07</date>
...

。。。
测试名称
2020-01-07
...

400将是：

...
  <name>test name</name>
  <dateString>2020-01-07</dateString>
...

...
  <name>test name</name>
  <date>hello</date>
...

。。。
测试名称
2020-01-07
...

422将是：

...
  <name>test name</name>
  <dateString>2020-01-07</dateString>
...

...
  <name>test name</name>
  <date>hello</date>
...

。。。
测试名称
你好
...

---

我只使用400，因为422没有在

中定义，我知道这个问题已经有将近一年的历史了，但我想我应该根据自己的经验添加一个答案，设计和构建一个跨越近400个微服务的非常大的API域

理想情况下，API应该遵循Postel定律，并对接收到的内容保持宽容。这有助于我们明确何时使用

400

以及何时使用

422

在上面的回答中，我们将示例400响应视为422响应。为什么？因为我们可以通过忽略“未知”属性来容忍它。但是所需的

字段丢失，因此我们将返回一个422，其中包含一个错误指示

如果消费者通过

应用程序/xml

内容类型下的JSON有效负载发送，或者如果xml请求无效（即，他们有

2020-01-07

字段），则会引发400响应

这种方法给我们的一个优势是，我们可以为422个响应定义一个不同的响应契约，同时允许400个响应保持相当通用的“WTF you you Thing ask？”响应。我们的422响应包含一组错误消息，其中列出了每个被破坏的请求约束或需求

---

我们还发现，这种方法对于我们的UX人员特别有用，他们可以向API提交表单，并返回带有人类可读错误的响应，他们可以直接映射回表单字段（即，点击submit并没有填写强制字段将生成422响应，其中包含一条消息，说明属性是必需的）.

解决方案现实地说，没有任何客户端实现会被编程为关心——这两个都是无法自动恢复的错误，如果重复请求，也不会产生不同的结果，而且都是4xx错误，这一点很重要。根据标准的解释方式，讨论绝对、积极、最正确的使用价值，更多的是纯粹的信仰，并将其作为一种胡说八道。“有很多讨论[…]我还不清楚”-请首先提及你的发现，每一条讨论线索都提到了这些HTTP代码定义中已经写下的内容。这些定义不能很好地解释特定场景。我遇到了描述中提到的一个场景（缺少强制属性的情况），我需要理解如何将这些HTTP状态代码的概念推广到任何场景。会有其他人遇到同样的问题。因此，无论你做什么决定，你都会遇到那些期望你做相反事情的客户。在这种情况下，你最好只挑选一些东西（在这种情况下，400是最明显的，因为每个客户都会支持它），然后在实际的兼容性问题得到证明之前暂停。更重要的是要清楚地记录并给出描述性错误，而不是准确地获得错误编号。“语法错误”-这是RFC2616文本，现在的解释过于狭窄。您链接到的RFC7231提到“表示服务器无法或不会处理请求，原因是被认为是客户端错误（例如，格式错误的请求语法、无效的请求消息帧或欺骗性的请求路由）”。缺少的XML元素和无关的XML元素（

date

vs

dateString

）在语法上都是有效的（在XML和HTTP中）。你的两个例子都可以得到400和422的回复。