使用RESTful API进行承诺控制的最佳实践

Question

我们目前正在设计一个使用RESTful API与数据库通信的应用程序。我们的数据库是一个规范化的结构，最多有7个表，表示一个应用程序数据点，每个数据库实体都有一个API。

我正在努力解决的是如何对这些表格进行承诺控制。理想情况下，我想从我的API控制器调用每个API，但这会使提交范围达到表级别，并使应用程序控制回滚。这并不理想，因为这意味着我们实质上在做脏写。

使用RESTful API并使数据库执行承诺控制的最佳做法是什么？

Answer 1

作为一组RESTful资源公开的模型不必与数据库使用的模型相同。例如，您可以使用RESTful操作来构建“更改描述”资源（用户会话的本地资源），然后在一次提交中将其应用于数据库。更改描述很复杂，但脏写不存在问题，因为所有用户都在更改私有世界，直到他们选择要提交它为止。

如果你想到一个基于网络的模型（对REST有用的话），那就像在多个阶段填写一个复杂的订单表格。您快乐购买的公司允许您填写表格，根据需要存储价值，但不承诺实际完成订单并从您的信用卡收费，直到您说它已准备就绪。我相信你可以将同样的原则应用于其他复杂的修改。

但关键是一件事;如果承诺不是幂等的（即，如果你提交两次，会发生不同的事情）， 必须 成为POST。无论如何，这在你的场景中可能是一个好主意，因为我猜你想在成功的POST上删除“建立一个动作描述”资源。 （是的，我们仍然会遵循“网络表单”模式。）

---

我确实认为你想仔细考虑模型的复杂性。让事情变得尽可能简单（虽然不简单）是一项非常有用的练习，其中“简单”涉及保持概念的数量。如果你有很多东西，但它们都以完全相同的方式工作，它们实际上非常简单。 （增加客户记录中的地址行数并不会真正增加复杂性。）REST的好处在于它使用的概念很少，而且它们是很多人都熟悉的概念。

Answer 2

为RESTful服务实现所需的控制器。控制器只需调用管理​​事务的服务层。服务层通过DAO需要合作的协调来协调对各种表的访问 - DAO不需要关注事务边界。如果您恰好是Spring用户，this线程可能会有所帮助。