我们正在开发一个REST API，其中客户端（应用程序）将调用我们的REST API。
客户端（应用程序）将使用回滚功能处理业务逻辑（例如，如果更新“发货”服务[通过]并更新“库存”服务[失败]，客户端可以回滚）。
有许多关于TCC [尝试/确认/取消]的在线文章描述了通过POST / DELETE方法保留/取消资源但没有描述如何处理PUT请求（例如，更新“Stock”计数1和故障时回滚）。
任何人都知道处理PUT回滚的解决方案（因为PUT请求会覆盖原始数据，我们如何回滚到原始数据）？
TCC只是使用HTTP / REST实现事务行为的概念。它涵盖了如何对交易建模的标准，包括超时和取消。在此模型中，事务绑定到具有id的任何类型的资源，因此您可以在任何时候确认或取消它。由于交易超时，您最终可能会产生无效或不再存在的交易。
无论您从交易的开始到结束做什么都取决于您。但是你需要一些东西来识别交易。由于使用PUT覆盖资源本身不会创建资源对象，因此您需要一种虚拟资源来执行此操作。
您可以创建资源的新版本（可能使用locking）（entities只是一个占位符）：
PUT /entities/42 - >链接rel:tcc，href：/entities/42/version/7PUT application/tcc /entities/42/version/7DELETE /entities/42/version/7如果您有这样的版本，您也可以考虑一种会话ID，而不是版本。
根据TCC模式，confirm操作使用PUT作为其幂等特征。当实现此类行为时，如果确认部分保留而其他人已过期，我们可以使用cancel操作来模拟回滚行为，以便每个确认的参与者链接将与另一个DELETE请求一起发送。我在预订系统中写了一篇关于Java最小TCC实现的tutorial article。你可以参考那里的实现。