400 vs 422 对数据 POST 的响应 [英] 400 vs 422 response to POST of data

问题描述

我试图找出在不同场景下使用类似 REST"返回的正确状态代码.我正在开发的 API.假设我有一个端点，允许以 JSON 格式进行 POST 购买.它看起来像这样:

I'm trying to figure out what the correct status code to return on different scenarios with a "REST-like" API that I'm working on. Let's say I have an end point that allows POST'ing purchases in JSON format. It looks like this:

{
    "account_number": 45645511,
    "upc": "00490000486",
    "price": 1.00,
    "tax": 0.08
}

如果客户向我发送sales_tax"，我应该返回什么?(而不是预期的税收").目前，我要退回 400.但是，我已经开始质疑自己了.我真的应该退回 422 吗?我的意思是，它是 JSON(受支持)并且它是有效的 JSON，只是不包含所有必需的字段.

What should I return if the client sends me "sales_tax" (instead of the expected "tax"). Currently, I'm returning a 400. But, I've started questioning myself on this. Should I really be returning a 422? I mean, it's JSON (which is supported) and it's valid JSON, it's just doesn't contain all of the required fields.

推荐答案

400 Bad Request 现在似乎是最适合您的用例的 HTTP/1.1 状态代码.

400 Bad Request would now seem to be the best HTTP/1.1 status code for your use case.

在您提出问题时(以及我的原始答案)，RFC 7231 不是一个东西；那时我反对 400 Bad Request 因为RFC 2616 说(强调我的):

At the time of your question (and my original answer), RFC 7231 was not a thing; at which point I objected to 400 Bad Request because RFC 2616 said (with emphasis mine):

服务器无法理解请求由于语法错误.

并且您描述的请求是包含在语法有效的 HTTP 中的语法有效的 JSON，因此服务器对请求的语法没有任何问题.

and the request you describe is syntactically valid JSON encased in syntactically valid HTTP, and thus the server has no issues with the syntax of the request.

但是 正如 Lee Saferite 在评论中指出的，RFC 7231 废弃了 RFC 2616，不包括该限制:

400 (Bad Request) 状态码表示服务器由于被认为是客户端错误(例如，格式错误的请求语法、无效的请求消息帧或欺骗性的请求路由)而无法或不会处理请求.

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

---

但是，在重新措辞之前(或者如果您想对 RFC 7231 目前只是一个提议的标准提出质疑)，422 Unprocessable Entity 似乎不是您用例的不正确 HTTP 状态代码，因为 RFC 4918 的介绍说:

---

However, prior to that re-wording (or if you want to quibble about RFC 7231 only being a proposed standard right now), 422 Unprocessable Entity does not seem an incorrect HTTP status code for your use case, because as the introduction to RFC 4918 says:

虽然 HTTP/1.1 提供的状态码足以描述 WebDAV 方法遇到的大多数错误情况，有是一些不完全属于现有类别的错误.该规范定义了为 WebDAV 开发的额外状态代码方法(第 11 节)

While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. This specification defines extra status codes developed for WebDAV methods (Section 11)

和422的描述说:

422(不可处理实体)状态码表示服务器了解请求实体的内容类型(因此415(不支持的媒体类型)状态代码不合适)，以及请求实体的语法是正确的(因此是 400(错误请求)状态代码不合适)但无法处理包含的说明.

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions.

(注意对语法的引用；我怀疑 7231 也部分过时了 4918)

(Note the reference to syntax; I suspect 7231 partly obsoletes 4918 too)

这听起来完全像你的情况，但以防万一有任何疑问，它继续说:

This sounds exactly like your situation, but just in case there was any doubt, it goes on to say:

例如，如果 XML请求正文包含格式正确(即语法正确)，但语义错误的 XML 指令.

For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

(用JSON"替换XML"，我想我们可以同意这就是你的情况)

(Replace "XML" with "JSON" and I think we can agree that's your situation)

现在，有些人会反对 RFC 4918 是关于Web 分布式创作和版本控制 (WebDAV) 的 HTTP 扩展"；并且你(大概)没有做任何涉及 WebDAV 的事情，所以不应该使用它的东西.

Now, some will object that RFC 4918 is about "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)" and that you (presumably) are doing nothing involving WebDAV so shouldn't use things from it.

如果可以选择使用原始标准中明确未涵盖情况的错误代码，以及使用准确描述情况的扩展中的错误代码，我会选择后者.

Given the choice between using an error code in the original standard that explicitly doesn't cover the situation, and one from an extension that describes the situation exactly, I would choose the latter.

此外，RFC 4918 第 21.4 节 指的是 IANA 超文本传输​​协议 (HTTP) 状态代码注册表，其中422 可以找到.

Furthermore, RFC 4918 Section 21.4 refers to the IANA Hypertext Transfer Protocol (HTTP) Status Code Registry, where 422 can be found.

我建议 HTTP 客户端或服务器使用该注册表中的任何状态代码是完全合理的，只要它们正确执行即可.

I propose that it is totally reasonable for an HTTP client or server to use any status code from that registry, so long as they do so correctly.

但从 HTTP/1.1 开始，RFC 7231 具有吸引力，因此只需使用 <代码>400 错误请求！

But as of HTTP/1.1, RFC 7231 has traction, so just use 400 Bad Request!

这篇关于400 vs 422 对数据 POST 的响应的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！