Http 响应 207 MULTI-STATUS 是否适合多任务操作？答案

【问题标题】：Is Http response 207 MULTI-STATUS appropriate for multi task operations?Http 响应 207 MULTI-STATUS 是否适合多任务操作？
【发布时间】：2021-12-10 09:36:35
【问题描述】：

我发现 Http 207 可用于批量插入/删除/...等操作，我们可能会插入多个项目，从业务角度来看，部分成功是可以的。

我想知道如果我们有 API Post 调用一些外部服务，是否同样适用？

示例业务场景：

我们有正在创建订单的 HttpPost 端点。

HttpPost:
/api/order/

现在让我们假设这个端点除了创建一个订单外，还会调用外部服务来打印该订单的标签，另一个通过 REST 向外部第 3 方系统发送某种确认。

现在在这种情况下，我们假设创建订单是此操作成功的必要条件，但打印和外部 REST 调用都可能返回错误消息。这可能超出了我们的控制范围。

现在从我读到的关于如何返回此信息的选项将是：

Http 200 带有某种包含必要信息的对象。例如： { "isSucess": true, "isFailure": true, "erorMesage": "string" }
使端点更加 RESTful，并将其分成 3 个将被调用的操作，但在这种情况下，这不适用（至少从我的角度来看），因为从业务角度来看，所有这些东西都是紧密耦合的，它们应该被绑定一起
返回 5xx 错误。 502，因为并非所有操作都成功并且存在一些内部问题，但是如果一个失败的操作是 502 和另一个 503，该怎么办
返回 207 错误并为每个操作提供正确的错误响应（订单创建：200，打印：502，外部第三方：502）

现在我想知道哪个最合适？我有点倾向于 502 错误或 207，因为我认为它们提供了有关系统实际状态的最多信息。

【问题讨论】：

标签： rest web-services http-status-codes

【解决方案1】：

这是一个关于如何将 REST Web 服务用于嵌套分布式事务的设计问题。有很多合适的答案。这是我对此的看法，我在参考 REST 规范的同时解决了您的每个观点。

HTTP 代码 207 不是一个好主意 - 此返回代码 (207) 是为支持 HTTP 上的 WebDAV (https://en.wikipedia.org/wiki/WebDAV) 扩展的系统指定的。 WebDAV 是分布式的，但它是一种规范

允许用户代理直接以协作方式创作内容 HTTP 网络服务器

WebDAV 并不是专门为分布式事务构建的。可以处理返回码 207 的服务器需要在其中安装 WebDAV 模块。您甚至可能无法在多个 REST 库中获得此返回码的支持。例如，此 API 文档没有代码 207。https://docs.oracle.com/javaee/7/api/javax/ws/rs/core/Response.Status.html（这是一个极端情况，但有助于说明问题）。

如果请求得到部分满足，我不喜欢使用 HTTP 50x。让我们以服务器创建订单但无法将其发布到第三方 REST 服务器（该服务器已关闭或网络错误）的情况为例。这是 50 倍错误的规范https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html：

“以数字“5”开头的响应状态码表示在服务器知道它有错误或无法做到的执行请求。 "

这里的服务器没有故障。它已经创建了实体。

我的建议是在POST /api/order/ 上返回HTTP cod 202，返回对订单的引用并异步处理这些步骤。此请求涉及多个事务 - 打印标签、更新第三方 REST 端点等。这些可以在“订单”资源中更新。例如，POST /api/order/ 可以以这种格式返回：

HTTP 状态 202（已接受） { “命令”： { “id”：“1234567” } }

客户端应使用GET /api/order/检查完整状态，这将返回个人状态：

{ “id”：1234567，“label_printed”：“失败”，“third_party_updated”： “成功”}

如果一个订单的任何子交易失败并且应该重新处理，它是对现有订单的更新，并调用PUT /api/order/，因为PUT方法是更新资源。服务器将接受 PUT 请求并根据需要重试事务。

这里有一些适合这个问题的附加答案：

Transactions in REST?

Transactions across REST microservices?

【讨论】：