哪些情况下在 Rest Api 中返回 400 HTTP 代码答案

【问题标题】：Which cases to return 400 HTTP Code in Rest Api哪些情况下在 Rest Api 中返回 400 HTTP 代码
【发布时间】：2022-01-22 07:52:21
【问题描述】：

我对何时在任何 REST API 中返回 400 Http 代码有些疑问。我解释接下来的三种情况：

当某些参数值不符合要求时，例如字符串的长度或数字的范围，我将返回 400
当用户想要在我们的系统中执行一些“动作”但在它之前，我们应用一些业务逻辑来验证这个请求，如果它有效我们执行那个动作，如果验证是 KO，我们应该返回 400 吗？我会
最后一个更让我困惑，如果我们公开一些休息方法调用，它的目的只是用业务逻辑规则验证某些东西，例如我们公开一个方法，以便客户端可以调用我们来验证某些商品的购物，如果任何业务验证规则没有通过，我们是否应该在这种情况下返回 400？我想我不会，因为此请求的最终目标是验证某些内容，并且已成功执行，尽管在验证过程中某些业务验证规则未通过。

你同意吗？谢谢

【问题讨论】：

【解决方案1】：

对于 1) 和 2) 应返回 400 http 状态码。

对于 3) 它取决于业务验证规则。如果是由于用户权限，403 将是一个正确的 http 状态代码。如果某些事情是由于不存在（不再存在）的资源造成的，则 404 将是要选择的状态代码。 409 也是一个状态码，在许多业务规则场景中都很有用。如果没有其他 4xx 状态代码出现缩进，请使用 400。

在此处查看完整的 http 状态代码列表及其说明： https://datatracker.ietf.org/doc/html/rfc7231#section-6.5

【讨论】：

我对第 3 点的意思是，也许我应该返回 200，并在响应中返回失败的业务验证规则消息
不，那肯定是错的。 200 表示成功，如果有的话，不管它是什么，失败你不能发送状态 200。
但是，如果我提到的方法本身只是应用验证规则，而一个规则是他不能购买 5 件商品，我应该返回一些 400 吗？请求很好，处理还可以
不，400 表示一切正常。这意味着一切都很好。当应该通知用户某些与预期不符的事情时，400 不是您会选择的。但是，如果用户会购买 5 件商品但只购买了 4 件，并且用户不想知道这一点（这对我来说似乎很奇怪），那么 400 将是要走的路。但正如我所提到的，这没有多大意义，因为您总是想告诉用户一些与预期不同的事情。

【解决方案2】：

基本原理是只要客户端的请求不符合预期（缺少强制参数、格式错误等），就返回一个 400 HTTP 状态码

因此，对于情况 1)，您应该返回 400。

对于情况 2) 和 3)，取决于具体的验证规则。例如，如果您的验证规则是关于请求内容的结构或值或客户端可以修复的其他内容，那么您可以返回 400。

如果验证规则以某种方式涉及授权上下文，则应使用 401、403 甚至 404。更多详情请看这篇文章：https://auth0.com/blog/forbidden-unauthorized-http-status-codes/

【讨论】：