如果表单提交包含验证错误，我应该回复 400 错误吗？答案

【问题标题】：Should I respond with a 400 error if a form submit contains validation errors?如果表单提交包含验证错误，我应该回复 400 错误吗？
【发布时间】：2015-04-03 07:32:47
【问题描述】：

在经典的基于表单的 web 应用中，如果用户提交的 HTML 表单包含验证错误，假设没有 JavaScript，那么正确的做法是什么？

响应 HTTP 200 + 页面内容（包括用户的错误信息）
响应 HTTP 400 + 页面内容（包括用户的错误信息）

重要吗？

【问题讨论】：

如果不是协议问题，抛出 HTTP 错误代码会很奇怪。如果验证错误，则不属于由于语法错误导致服务器无法理解请求的 400 秒描述。（验证甚至不应该能够运行，服务器不理解请求）。
那是 RFC2616，现在已被 RFC7230-RFC7235 淘汰。 RFC7231 提供了更多的边界定义，可以涵盖验证错误。 WebDAV 提供了一个似乎更合适的状态码 422。因此，如果它是一个 API，我会发送 422。对于人们使用的网站，如果您不希望浏览器以不同的“用户友好”方式呈现错误消息，则 200 可能是合适的。

标签： html forms http web http-status-codes

【解决方案1】：

一方面，如果它是供人类消费的网络应用程序，则带有一些有用错误消息的 200 将起作用。从这个意义上说，为人类制作网站更容易，因为他们可以阅读和理解内容，而不必依赖状态代码与应用程序交互。

另一方面，如果您考虑使用 REST API 更合适的是抛出 4xx 错误，因为它是客户端错误。在这种情况下，您有多种选择。

根据RFC2616，400 表示

由于格式错误，服务器无法理解请求句法。客户端不应该重复请求修改。

这似乎不合适，因为它不是由于语法错误。

但是，RFC2616 is now obsoleted by RFC7230-7235。新的RFC7231 以更广泛的方式定义了 400 的含义。

Client Error 4xx 4xx（Client Error）类状态码表示客户似乎犯了错误。响应 HEAD 时除外请求，服务器应该发送一个包含错误情况的解释，以及它是暂时的还是永久状态。

400 错误请求

400（Bad Request）状态码表示服务器不能或由于某些被认为是客户端错误（例如，格式错误的请求语法、无效请求消息框架或欺骗性请求路由）

所以这似乎是可以接受的，尽管仍然是通用的。另一种选择是使用由RFC4918 (WebDAV) 定义的422 status code。

422 Unprocessable Entity 422（Unprocessable Entity）状态码表示服务器了解请求实体的内容类型（因此 415（不支持的媒体类型）状态码是不合适的），并且请求实体的语法是正确的（因此 400 (Bad 请求）状态码不合适）但无法处理包含说明。例如，可能会出现这种错误情况如果 XML 请求正文包含格式正确的（即，在语法上正确），但语义错误的 XML 指令。

【讨论】：

【解决方案2】：

1) 将是正确的方法，因为您希望向用户显示突出显示无效输入值的内容页面。

2) 的问题在于，某些浏览器可能会显示自己的“友好”错误页面，该页面旨在帮助用户了解 4xx 错误。以下是有关 IE 何时显示“友好”错误页面的一些信息：

http://support.microsoft.com/kb/294807

【讨论】：

【解决方案3】：

您的应用正在与人类对话，而不是与其他机器对话。因此，您应该做正确的事情并以用户友好的方式处理异常。

您的用户并不关心 HTTP 返回代码，因此您也不应该考虑它。您将业务逻辑问题与 HTTP 协议问题混淆了。

事实上，通过向网络浏览器抛出 400 错误，您只可能遇到网络浏览器向用户抛出丑陋的消息。

如果您正在编写 REST api，那么答案会有所不同。但你不是。

【讨论】：