0

我觉得这个问题不是小事，所以想详细表达一下

领域：

我有一个端点（api rest），它接收我想要阻止的约会的日期和时间（稍后将被保留）。操作简单，收到日期和时间后，将其封锁，使其他客户无法在同一天和同一时间预约，而封锁预约的客户，完成联系信息。

到目前为止，非常简单。当两个不同的用户在他们的浏览器中选择相同的日期和时间并且同时触发两个请求时，问题就开始了。正如我们已经知道的，您不能在同一日期和同一时间两次阻止约会，因此应用程序将失败（尽管此失败得到了适当的控制）。

简而言之，两个用户尝试在同一日期和时间阻止约会，只有最先处理的请求才会成功。对于成功阻止约会的用户，答案很明确：200 OK 状态。问题是，返回给第二个用户的http对应的是哪个状态码？

评论：

最近在工作中，我遇到了这个困境，为此我与一位同事进行了激烈的争论。从那以后，我开始努力研究，并咨询了几个在这个领域有多年经验的人，以便能够得出一个结论。

  • 2xx：一半的人回答说州代码应该是 2xx。为什么？首先，因为请求是精心制定的（主要是参数，写得正确）所以它不会对应客户端错误（4xx），另一方面，它不是服务器的意外错误（500），因为它由业务逻辑本身适当控制。由于查询已正确完成，它应该发送一个 2xx 状态（更准确地说是 200）表示请求成功，并在正文上显示一条消息，指示操作的“状态”（无法阻止约会）。
  • 4xx：我的立场（以及其他 50% 的咨询者的立场）是，可以看出，请求失败是因为无法完成所需的操作。返回 200 OK（表示一切顺利）和描述发生的错误或情况的消息（在某​​种程度上，这与我相矛盾）似乎完全不合逻辑。发生错误时，只有两种可能有罪：客户端和服务器。在这种情况下，在我看来服务器不是，因为它不会意外失败，但该业务规则是经过深思熟虑的，并且故意失败（因此它不会是 5xx）。当尝试对同一资源执行两次相同的操作时，一切似乎都符合客户端错误，也许是语义错误。因此，我的观点是错误 400 会根据情况进行调整，

对于这种情况，什么应该是合适的选择？

谢谢！

4

1 回答 1

-1

让我们看看 Wikipedia 和 MDN 对此提供了什么：

2xx（成功）：请求被成功接收、理解并接受

4xx（客户端错误）：请求包含错误的语法或无法完成

（来源：https ://en.wikipedia.org/wiki/List_of_HTTP_status_codes ）

在约会冲突的情况下，第二个用户的请求被接收并理解但不能被接受，因此在这种情况下返回 2xx 似乎是错误的。

当请求包含错误的语法（此处不是这种情况，因为请求格式正确）或无法满足请求时（这似乎是您想要回信的情况），情况符合 4xx 条件给客户）。对于特定于业务用例的此类错误（例如您的案例的约会安排程序），建议可以继续使用 422

根据 MDN：

超文本传输​​协议 (HTTP) 422 Unprocessable Entity 响应状态码表示服务器理解请求实体的内容类型，请求实体的语法正确，但无法处理包含的指令。

（来源：https ://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422 ）

此外，由于预订约会会在后端创建一个资源（即包含访客、时间等详细信息的有效约会 ID），我更愿意将成功案例的 201（已创建）状态代码发送回您正在以同步方式执行任务。在我看来，200（OK）状态码更适合资源将被异步创建并且在服务器响应回客户端时可能不会立即可用的情况。在这种情况下，我们通常会提供一个 GET 请求链接，客户端将来可以从中获取请求的资源。

于 2019-01-12T05:57:14.017 回答