RESTful 服务，如果验证失败如何响应？

Posted 2023-03-03

【中文标题】RESTful 服务，如果验证失败如何响应？

【英文标题】：RESTful service, how to respond if validation failed?

【发布时间】：2012-02-15 04:21:05

【问题描述】：

我的服务需要一些实体并且需要保存/更新这个实体：

http://myhost.com/rest/entity

我使用 POST 并提交 JSON。在服务内部，它检测到传递的实体不好。无效，与不存在的客户一起传递的订单等。

我该如何回复？ HttpCode.NotFound?还是其他人？你怎么回复这样的事情？

【问题讨论】：

嗯，这完全由您决定，这是您的服务。

REST HTTP status codes for failed validation or invalid duplicate 的可能重复项

【参考方案1】：

在我们的项目中，在这种情况下，我们会执行以下操作：

将响应代码设置为 HTTP 400 错误请求 将响应正文设置为以下 JSON："message":"%extended error message here%"

但这真的很主观。

我还建议阅读This blog article on RESTfull error handling - 它描述了许多可用的选项，因此您可以根据自己的喜好选择一些东西。

【讨论】：

这就是我们所做的。如果可用，我们会返回相同的媒体类型。在网络世界中，您会得到一个带有 text\html 的 400。在此示例中，媒体类型为 application\json

谢谢！除了状态代码之外，我还在考虑在标题中传递一些信息，但是在你提到的文章和这篇文章之间，我想我会决定我的服务的通用响应对象，并且只使用 400 和 200 代码（除了 401 用于身份验证）跨度>

如果你要返回验证错误，那么 400 就足够了

【参考方案2】：

我认为你应该选择client error code。 400 Bad Request 或 403 Forbidden 可能是一个好的开始

【讨论】：

418 是显而易见的选择。

403 不适合所描述的场景。

为什么403不合适？ ***.com/a/3290369/59639 似乎在 400 和 403 上有不同的流派

【参考方案3】：

422 Unprocessable Entity, defined in WebDAV (RFC 4918):

422（Unprocessable Entity）状态码表示服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此 400 （错误请求）状态代码不合适）但无法处理包含的指令。例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会发生这种错误情况。

【讨论】：

我真的很喜欢这个。它可能不会受到纯粹主义者的欢迎，但使用与格式错误的请求相同的状态要好得多。

在我正在处理的项目中，我也很困扰客户无法仅从状态代码中区分验证错误和格式错误的请求（不检查响应正文），并且独立想到用422来区分前者。我在进行一些健全性检查搜索以确保没有更好的选择时遇到了这个问题，所以我很高兴看到其他人使用了这种方法并且这并不是完全超出了左领域。我可以假设你们都没有遇到这种方法的其他下游问题吗？

这就是我所做的，因为 400 的常用用法在技术上确实不正确，因为请求还不错。