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