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