服务器是否应该在 400 Bad Request 上返回错误页面或再次呈现表单

Question

我有一个带有页面和表单的基本网络应用程序（不是 api）。如果用户发送例如使用无法验证的值注册表单，我再次使用 status 422 呈现表单页面，指示错误输入的位置。

当语法格式错误时，是否应该向用户显示错误页面并显示代码 400 Bad request，或者是否应该再次呈现注册表单页面并显示请求正文格式错误的消息（响应仍然是 400)？

我的想法： 错误页面的参数：如果前端（客户端）在没有或带有错误正文的情况下发送 POST 请求，似乎有问题。要么必须修复前端，要么操纵请求正文。如果用户正常发送表单并且前端没有故障，则永远不会发生这种情况。

*我为什么怀疑：我不能 100% 确定它不可能是客户端的临时错误，也可能是网络问题或其他原因。如果这是合理的，则必须再次将用户重定向到表单，并提供请求正文错误的信息。他应该可以再试一次。 我的相关问题基本上是这样的：在正常的操作流程中，服务器是否有可能收到带有错误正文的请求？

Answer 1

尝试将应用程序的每个部分“深度”映射到 HTTP 状态代码是错误的；在大多数情况下，您要瞄准的粒度级别要粗得多。如有疑问，可以在没有更合适的情况下使用通用状态代码 200 OK、400 Bad Request 和 500 Internal Service Error。

422 vs 400 细化，这些代码通常是针对开发人员而不是最终用户的（除非您的最终用户是开发人员）。这可以帮助您查看日志并找出到底发生了什么。如果表单上有错误，我只会为用户呈现一条验证消息，表明出现问题，或者您可以通过验证了解更多详细信息。

您可以使用像 Sentry 这样的工具来提供实际错误的堆栈跟踪。