我花了20分钟调试一些(django)单元测试.我正在测试一个视图POST,我期待一个302返回代码,之后我断言了一堆数据库实体正如预期的那样.原来最近合并的提交添加了一个新的表单字段,我的测试失败了,因为我没有包含正确的表单数据.
问题是测试失败了,因为HTTP返回代码是200而不是302,我只能通过打印响应HTTP并查看它来解决问题.除了必须通过HTML来解决问题的烦恼之外,200似乎是一个没有得到处理的POST的错误代码.4xx(客户端错误)似乎更合适.此外,它会使测试变得简单,因为响应代码会直接指出我的问题.
我已经读过使用422(不可处理的实体)作为REST API中可能的返回代码,但是在HTML视图/处理程序中找不到任何使用它的证据.
我的问题是 - 是否有其他人这样做,如果没有,为什么不呢？
[ 更新1 ]
只是为了澄清,这个问题与HTML表单有关,而不是API.
这也是关于HTTP响应代码本身的问题 - 而不是Django.这恰好就是我正在使用的东西.我删除了django标签.
[ 更新2 ]
W3C参考文献进一步澄清(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html):
10.2成功2xx
此类状态代码表示已成功接收,理解和接受客户端的请求.
10.4客户端错误4xx
4xx类状态代码适用于客户端似乎有错误的情况.
10.4.1 400错误请求
由于语法格式错误,服务器无法理解请求.
来自https://tools.ietf.org/html/rfc4918#page-78
11.2. 422不可处理的实体
422(不可处理实体)状态代码表示服务器理解请求实体的内容类型(因此415(不支持的媒体类型)状态代码是不合适的),并且请求实体的语法是正确的(因此400(错误请求) )状态代码不合适)但无法处理包含的指令.例如,如果XML请求主体包含格式正确(即语法正确)但语义错误的XML指令,则可能发生此错误情况.
[ 更新3 ]
深入研究,422是WebDAV扩展[1],这可能解释其默默无闻.也就是说,由于Twitter为了自己的目的使用420,我想我会满足于我想要的任何东西.但它将以4开头.
[ 更新4 ]
关于使用自定义响应代码的说明,以及如何处理它们(如果无法识别),来自HTTP 1.1规范(http://tools.ietf.org/html/rfc2616#section-6.1.1):
HTTP状态代码是可扩展的.HTTP应用程序不需要理解所有已注册状态代码的含义,尽管这种理解显然是可取的.但是,应用程序必须理解任何状态代码的类,如第一个数字所示,并将任何无法识别的响应视为等同于该类的x00状态代码,但不得高速缓存无法识别的响应.例如,如果客户端收到无法识别的状态代码431,则可以安全地假设其请求有问题并将响应视为已收到400状态代码.在这种情况下,用户代理应该向用户呈现随响应返回的实体,因为该实体可能包括将解释异常状态的人类可读信息.
你是对的，如果结果不成功，200 就是错误的。
我还认为成功重定向到结果页面应该是 303，而不是 302。
4xx 对于客户端错误来说是正确的。422 对我来说似乎是正确的。无论如何，在未通过 IANA 注册的情况下，请勿发明新的 4xx 代码。