Http响应207多状态是否适合于多任务操作？
我发现Http 207可以用于批量插入/删除/.等等，从业务的角度来看，我们可能会插入多个项目并部分成功的操作是可以的。
我想知道，如果我们有API Post调用一些外部服务，同样的情况是否适用？
示例业务场景：
我们有创建订单的HttpPost端点。
HttpPost:
/api/order/现在，假设除了创建订单之外，这个端点还将调用外部服务来打印该订单的标签，而另一个端点将通过REST向外部第三方系统发送某种确认。
现在，在这个场景中，我们假设创建顺序是此操作成功的必要条件，但是打印和外部REST调用都可以返回错误消息。这可能是我们无法控制的。
现在，根据我所读到的关于如何返回这些信息的选项，应该是：
- 带有某种包含必要信息的对象的Http 200。例如：
{ "isSucess": true, "isFailure": true, "erorMesage": "string" } - 使端点更加RESTful，并将其分离为三个将被调用的操作，但在本例中这是不适用的(至少从我的角度来看)，因为所有这些事情都是从业务角度紧密耦合的，应该将它们绑定在一起。
- 返回5xx错误。502因为并不是所有的行动都成功了，并且有一些内部问题，但是如果一个失败的行动是502和另一个503呢？
- 为每个操作返回带有正确错误响应的207错误(订单创建: 200，打印: 502，外部第三方: 502)
现在我想知道哪一个最合适？我倾向于502错误或207，因为在我看来，它们提供了关于系统实际状态的大部分信息。
回答 1
Stack Overflow用户
发布于 2021-12-31 04:23:19
这是一个关于如何将REST服务用于嵌套分布式事务的设计问题。有许多合适的答案。这里是我对此的看法，在这里，我将讨论您的每一个要点，同时引用其他规范。
- HTTP代码207不是一个好主意-这个返回代码(207)是为支持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 (这是一个边缘情况，但它有助于说明要点)。
- 如果请求部分得到满足，我不喜欢使用HTTP50x。如果服务器已经创建了订单，但无法将其发送到第三方REST服务器(该服务器已经故障或网络错误)，那么就让我们来看看吧。以下是50x错误https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html的规范
以数字"5“开头的响应状态代码表示服务器知道其错误或无法执行请求的情况。
服务器在这里没有错。它创造了这个实体。
- 我的建议是在
POST /api/order/上返回HTTP 202，返回对订单的引用并异步处理这些步骤。此请求涉及多个事务-打印标签、更新第三方REST端点等。这些事务可以在"order“资源中更新。例如，POST /api/order/可以以以下格式返回：
HTTP STATUS 202 (接受){ "order"：{ "id"："1234567“}}
客户端应该使用GET /api/order/检查完整的状态，这将返回单个状态：
{ "id"：1234567，"label_printed"：“失败”，"third_party_updated"：“成功”}
如果订单的任何子事务失败并应该重新处理，则是对现有订单的更新和对PUT /api/order/的调用，因为PUT方法是更新资源。服务器将接受PUT请求并根据需要重试事务。
以下是一些适合这个问题的其他答案：
https://stackoverflow.com/questions/70302432
复制相似问题
腾讯云开发者
