我只花了 20 分钟调试一些 (django) 单元测试。我正在测试一个视图 POST，我期待一个 302 返回码，之后我断言一堆数据库实体符合预期。原来最近合并的提交添加了一个新的表单字段，我的测试失败了，因为我没有包含正确的表单数据。
问题是测试失败了，因为 HTTP 返回码是 200，而不是 302，我只能通过打印响应 HTTP 并查看它来解决问题。除了必须通过 HTML 来解决问题的烦恼之外，对于未处理的 POST，200 似乎是错误的代码。4xx（客户端错误）似乎更合适。此外，它会使调试测试变得轻而易举，因为响应代码会直接指出问题所在。
我已经阅读了有关在 REST API 中使用 422（不可处理实体）作为可能的返回代码的信息，但找不到在 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://www.rfc-editor.org/rfc/rfc4918#page-78
11.2. 422 无法处理的实体
422（Unprocessable Entity）状态码意味着服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此是 400（Bad Request） ) 状态码不合适）但无法处理包含的指令。例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会出现这种错误情况。
[更新 3 ]
深入研究它，422 是一个 WebDAV 扩展[1]，这可能解释了它的晦涩难懂。也就是说，由于 Twitter 将 420 用于他们自己的目的，我想我会随心所欲。但它会以 4 开头。
[更新 4 ]
来自 HTTP 1.1 规范 ( https://www.rfc-editor.org/rfc/rfc2616#section-6.1.1 )中关于使用自定义响应代码以及如何处理它们（如果无法识别）的说明：
HTTP 状态代码是可扩展的。HTTP 应用程序不需要理解所有注册状态码的含义，尽管这样的理解显然是可取的。但是，应用程序必须理解任何状态代码的类别，如第一个数字所示，并将任何无法识别的响应视为等同于该类别的 x00 状态代码，但不得缓存无法识别的响应。例如，如果客户端收到无法识别的状态码 431，它可以安全地假设其请求有问题，并将响应视为收到 400 状态码。在这种情况下，用户代理应该向用户呈现与响应一起返回的实体，因为该实体很可能包含人类可读的信息，这些信息将解释异常状态。