有没有一种RESTful方法来确定POST（或任何其他非幂等动词）是否会成功？ 这在您基本上需要对不同服务执行多个幂等请求（其中任何一个都可能失败）的情况下似乎很有用。 如果这些请求可以在"事务"中完成（即支持回滚），那就太好了，但由于这是不可能的，另一种方法是在实际执行它们之前检查每个请求是否会成功。
例如，假设我正在构建一个电子商务系统，允许人们购买印有自定义文本的T恤，并且该系统需要与两种不同的服务集成：T恤打印服务和支付服务。 其中每个都有一个 RESTful API，并且任何一个都可能失败。 （例如，印刷公司可能会拒绝在T恤上打印某些文字，如果信用卡过期，银行可能会投诉。 有没有办法推测地执行这两个请求，因此我的系统只有在两个请求都有效时才继续执行它们？
如果没有，这个问题可以用不同的方式解决吗？ 通过带有 status = pending 的POST创建资源，并将其更改为 status = complete 如果所有请求都成功？ （DELETE更棘手...
为您的方案定义了 202 状态代码：
202 已接受
请求已被接受处理，但处理尚未完成。最终可能会或可能不会对请求执行操作，因为在实际进行处理时可能会不允许该请求。没有从此类异步操作重新发送状态代码的工具。
202 响应是故意不承诺的。其目的是允许服务器接受对某个其他进程（可能是每天仅运行一次的面向批处理的进程）的请求，而无需用户代理与服务器的连接一直持续到进程完成。与此响应一起返回的实体应包括请求当前状态的指示，以及指向状态监视器的指针或用户何时可以预期满足请求的某种估计值。
来源：HTTP 1.1 状态代码定义
这类似于 201 Created，不同之处在于您指示请求尚未完成且实体尚未创建。您的响应将包含指向表示"订单请求"的资源的 URL，因此客户端可以通过此 URL 检查订单的状态。
<小时 />更直接地回答你的问题：在你提出请求之前，没有办法"测试"请求是否会成功，因为你要求的是千里眼。
无法预见将来尝试发出请求时可能发生的技术问题的范围。网络可能不可用，服务器可能无法访问其数据库或它所依赖的外部系统，可能会断电并且服务器处于脱机状态，杂散的中微子可能会徘徊在您的内存中并将 0 变为 1，从而导致灾难性的内核故障。
为了使用远程服务，您需要考虑与任何其他进程隔离的任何请求可能失败的情况。
对于您的特定问题，如果服务没有事务安全性，则无法在其中烘焙任何服务，您必须以更真实的方式处理此问题。我脑海中的几个选项：
让T恤公司给你一个"测试"机制，这样你就可以看看他们是否会在不实际下订单的情况下处理任何给定的订单。向他们下订单可能是两阶段操作，您在第一阶段构建订单（此时他们验证其创建），然后您随后要求处理订单（在您成功付款后）。
首先使用信用卡付款，然后将订单移至"已付款"状态。然后尝试使用 T 恤服务作为异步流程履行订单。如果履行失败，并且您可以确定客户试图打印公司不准备生产的东西，则必须与他们联系以更改订单或退款。
大多数组织将采用第二种方法，因为它的技术简单性并降低了业务风险。它还具有能够应对 T 恤服务不可用的好处;异步进程只是等到服务可用并在那时完成订单。
没错。这可以按照你在最后一句话中的建议去做。这个想法是取消资源创建（除非网络故障，否则将始终有效），它代表"订单接受"的"持续请求"，可以在以后决定。由于 POST 返回"位置"标头，您可以随时检索请求的"状态"。
在某些时候，它可能会被接受或拒绝。这可能是有意的，或者可能需要一些时间，因此您必须使用这些限制来设计您的服务（即允许客户检查他/她的订单是否被接受，或运行某种每小时/每天的服务来收集接受的请求）。