400与422响应POST的数据
我试图找出正确的状态代码,以便在不同的场景下使用我正在处理的“类似休息”的API返回。 假设我有一个终点,允许以JSON格式进行POST'ing购买。 它看起来像这样:
{
"account_number": 45645511
"upc": "00490000486"
"price": 1.00
"tax": 0.08
}
如果客户向我发送“sales_tax”(而不是预期的“税”),我应该返回什么。 目前,我回来了400.但是,我已经开始质疑自己了。 我真的应该回来422吗? 我的意思是,这是JSON(支持),它是有效的JSON,它只是不包含所有必需的字段。
400错误请求现在看起来是您用例中最好的HTTP / 1.1状态码。
在你提出问题的时候 (以及我的原始答案),RFC 7231不是一件事; 在这一点上,我反对400 Bad Request
因为RFC 2616说(重点是我的):
由于格式错误 ,服务器无法理解请求。
并且您描述的请求是语法上有效的JSON,它包含在语法上有效的HTTP中,因此服务器对请求的语法没有任何问题。
然而,正如Lee Saferite在评论中指出的那样,RFC 7231废弃了RFC 2616,并没有包含这样的限制:
400(错误请求)状态码指示服务器由于被认为是客户端错误(例如,格式错误的请求语法,无效的请求消息帧或欺骗性请求路由)而不能或不会处理该请求。
但是, 在重新措辞之前 (或者如果您想歪曲RFC 7231仅仅是现在提出的标准), 422 Unprocessable Entity
无法422 Unprocessable Entity
似乎并不是您用例的错误HTTP状态代码,因为正如RFC 4918说:
虽然HTTP / 1.1提供的状态码足以描述WebDAV方法遇到的大多数错误情况,但有些错误并不完整地归入现有类别。 本规范定义了为WebDAV方法开发的额外状态代码(第11节)
而对422
的描述说:
422(不可处理的实体)状态码意味着服务器理解请求实体的内容类型(因此415(不支持的媒体类型)状态码不合适),并且请求实体的语法是正确的(因此400(错误请求)状态码不合适),但无法处理包含的说明。
(注意语法的引用;我怀疑7231也部分废弃了4918)
这听起来和你的情况完全一样,但如果有任何疑问,它会继续说:
例如,如果XML请求体包含格式正确(即,语法正确),但语义错误的XML指令,则可能会出现此错误情况。
(用“JSON”替换“XML”,我认为我们可以认同这就是你的情况)
现在,有些人会反对说RFC 4918是关于“Web分布式创作和版本控制的HTTP扩展(WebDAV)”,并且您(大概)没有涉及WebDAV,因此不应该使用它。
鉴于在原始标准中使用错误代码(明确不包括该情况)和使用描述情况的扩展名之间的选择,我会选择后者。
此外,RFC 4918第21.4节涉及IANA超文本传输协议(HTTP)状态代码注册表,其中可以找到422。
我建议对于HTTP客户端或服务器使用来自该注册表的任何状态代码是完全合理的,只要它们正确地执行。
但是从HTTP / 1.1开始,RFC 7231具有牵引力,因此只需使用400 Bad Request
!
反映截至2015年的状况:
在行为上,400和422响应代码将由客户和中介处理相同,所以它实际上不会产生您使用的具体差异。
不过,我期望看到目前使用的更广泛的400,此外,HTTPbis规范提供的澄清使其更适合两种状态代码:
对于上下文,HTTPbis是对HTTP / 1.1规范的修订,试图澄清哪些地方不清楚或不一致。 一旦达到批准状态,它将取代RFC2616。
400错误请求是您的用例的正确HTTP状态码。 代码由HTTP / 0.9-1.1 RFC定义。
由于格式错误,服务器无法理解请求。 客户端不应该在没有修改的情况下重复请求。
http://tools.ietf.org/html/rfc2616#section-10.4.1
422不可处理的实体由RFC 4918 - WebDav定义,只有在您支持WebDav功能时才应使用此代码。 此代码不是HTTP / x RFC的一部分。 请注意,与400相比略有差异,请参阅下面引用的文字。
如果XML请求主体包含格式正确(即语法正确)但语义错误的XML指令,则可能会出现此错误情况。
http://tools.ietf.org/html/rfc4918#page-78
链接地址: http://www.djcxy.com/p/7929.html上一篇: 400 vs 422 response to POST of data
下一篇: What is the http