问题描述
我有一个带有页面和表单的基本 Web 应用程序（不是 api）。如果用户发送一个例如使用无法验证的值注册表单，我再次使用 status 422 呈现表单页面，指示错误输入的位置。
如果语法格式错误，应该向用户显示代码为 400 Bad request 的错误页面，还是应该再次呈现注册表单页面并显示请求正文格式错误的消息（响应仍然是 400)？
我的想法： 错误页面的参数：如果前端（客户端）发送 POST 请求而没有或有错误的正文，则它似乎有问题。要么必须修复前端，要么操纵请求正文。如果用户正常发送表单并且前端没有故障，则永远不会发生这种情况*。
*我怀疑的原因：我不能 100% 确定这不可能是客户端的临时错误，也可能是网络问题或其他原因。如果这是合理的，那么用户必须再次重定向到表单，并提供请求正文错误的信息。他应该可以再试一次。 我的相关问题基本上是这样的：在正常的操作流程中，服务器是否有可能收到带有错误正文的请求？
解决方法
尝试将应用程序的每个部分“深入”映射到 HTTP 状态代码是错误的；在大多数情况下，您想要达到的粒度级别要粗得多。如有疑问，可以在没有更合适的情况下使用通用状态代码 200 OK、400 Bad Request 和 500 Internal Service Error。
422 与 400 归结为细化级别，这些代码通常是针对开发人员而非最终用户的（除非您的最终用户是开发人员）。这可以帮助您查看日志并弄清楚到底发生了什么。如果表单上有错误，我只会为用户呈现一条验证消息，表明出现问题，或者您可以通过验证了解更多详细信息。
您可以使用类似 Sentry 的工具来提供实际错误的堆栈跟踪。