400和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 a 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"(而不是预期的"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错误请求现在似乎是您的用例的最佳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):

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

The request could not be understood by the server due to malformed syntax.

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

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.

但是 RFC 7231 ，它淘汰了RFC 2616，但不包括该限制:

400(错误请求)状态码表示服务器由于某些原因(例如格式错误的请求语法，无效的请求消息框架或欺骗性的请求路由)而被视为无法处理或无法处理请求的原因

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 的描述是:

And the description of 422 says:

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.

(将"XML"替换为"JSON"，我想我们可以同意这是您的情况)

(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节指的是

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 Bad Request ！

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

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