validation - 是否有 RESTful 方法来确定 POST 是否会成功？

Question

是否有 RESTful 方法来确定 POST(或任何其他非幂等动词)是否会成功？在您基本上需要针对不同服务执行多个幂等请求的情况下，这似乎很有用，其中任何一个都可能失败。如果这些请求可以在“事务”中完成(即支持回滚)，那就太好了，但由于这是不可能的，另一种方法是在实际执行之前检查每个请求是否会成功。

例如，假设我正在构建一个电子商务系统，该系统允许人们购买印有自定义文本的 T 恤，该系统需要与两种不同的服务集成:T 恤打印服务和支付服务。其中每一个都有一个 RESTful API，并且可能会失败。 (例如，打印公司可能拒绝在 T 恤上打印某些文字，如果信用卡过期，银行可能会提示。)有没有办法推测性地执行这两个请求，所以我的系统只会继续如果两个请求都有效？

如果不是，这个问题可以用不同的方式解决吗？通过 POST 创建资源与 status = pending ，并将其更改为 status = complete如果所有请求都成功？ ( DELETE 比较棘手...)

Answer 1

HTTP 为您的场景定义了 202 状态代码:

202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

来源: HTTP 1.1 Status Code Definition
这与 201 Created 类似，不同之处在于您表示请求尚未完成且实体尚未创建。您的响应将包含一个指向代表“订单请求”的资源的 URL，因此客户可以通过此 URL 检查订单的状态。

更直接地回答你的问题:没有办法在你提出请求之前“测试”它是否会成功，因为 你要求千里眼。
当您将来尝试提出请求时，无法预见可能出现的技术问题范围。网络可能不可用，服务器可能无法访问其数据库或运行所依赖的外部系统，可能会断电且服务器离线，杂散的中微子可能会进入您的内存并撞到 0到 1 导致灾难性的内核错误。
为了使用远程服务，您需要考虑与任何其他进程隔离的任何请求的可能失败。
对于您的特定问题，如果服务没有事务安全性，您就不能在其中烘焙任何内容，您必须以更真实的方式处理这个问题。我脑子里有几个选项:

让 T-Shirt 公司给你一个“测试”机制，这样你就可以看看他们是否会在没有实际下单的情况下处理任何给定的订单。向他们下订单可能是一个两阶段的操作，您在第一阶段构建订单(此时他们验证其创建)，然后您随后要求处理订单(在您付款后成功地)。

首先进行信用卡付款，然后将您的订单转为“已付款”状态。然后尝试使用 T-Shirt 服务作为异步流程完成订单。如果履行失败并且您可以确定客户试图打印公司不准备生产的东西，您将不得不联系他们以更改订单或退款。

大多数组织将采用第二种方法，因为其技术简单且业务风险较低。它还具有能够应对 T-Shirt 服务不可用的好处；异步过程只是等待服务可用并在那时完成订单。