Html 如果表单提交包含验证错误，我是否应该以400错误作为响应？

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

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

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

---

这有关系吗？

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

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

事实上，通过向web浏览器抛出400错误，您很可能只会遇到web浏览器向用户抛出难看的消息

如果您正在编写RESTAPI，那么答案将不同。但你不是

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

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

---

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

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

根据一项调查，400意味着

由于格式错误，服务器无法理解该请求 语法。客户机不应在没有通知的情况下重复请求 修改

这似乎不合适，因为这不是由于语法错误造成的

然而。新的定义在更广泛的意义上400

客户端错误4xx状态代码的4xx（客户端错误）类别指示 客户似乎犯了错误。除了对头部做出反应 请求时，服务器应发送包含 说明错误情况，以及错误是暂时的还是暂时的 永久状态

400错误请求

400（错误请求）状态代码表示服务器无法或 由于被认为是错误的内容，将不处理请求 客户端错误（例如，格式错误的请求语法、无效的请求 消息帧或欺骗请求路由）

因此，这似乎是可以接受的，尽管仍然是通用的。另一种选择是使用定义的

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

---

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