问REST中的事务？

EN

考虑一个RESTful购物篮场景。购物篮在概念上是您的事务包装器。与将多个商品添加到购物篮，然后提交购物篮以处理订单的方式相同，您可以将Bob的帐户条目添加到事务包装器，然后将Bill的帐户条目添加到包装器。当所有组件都就位后，您就可以POST/PUT包含所有组件组件的事务包装器了。

有一些重要的情况没有被这个问题回答，我认为这太糟糕了，因为它在Google上的搜索词排名很高:-)

具体地说，一个很好的恰当方法是:如果你发布了两次(因为中间的一些缓存发生了问题)，你不应该两次转移数量。

为此，您需要创建一个事务作为对象。这可能包含您已经知道的所有数据，并将事务置于挂起状态。

POST /transfer/txn
{"source":"john's account", "destination":"bob's account", "amount":10}

{"id":"/transfer/txn/12345", "state":"pending", "source":...}

一旦你有了这个事务，你就可以提交它，就像这样：

PUT /transfer/txn/12345
{"id":"/transfer/txn/12345", "state":"committed", ...}

{"id":"/transfer/txn/12345", "state":"committed", ...}

请注意，此时多个puts并不重要；即使是txn上的GET也会返回当前状态。具体地说，第二个PUT将检测到第一个put已经处于适当的状态，并返回它--或者，如果您试图在它已经处于" committed“状态之后将其置于"rolledback”状态，您将得到一个错误，并返回实际提交的事务。

只要您与单个数据库或具有集成事务监视器的数据库通信，这种机制实际上就会工作得很好。您还可以为事务引入超时，如果您愿意，甚至可以使用Expires头来表示。

如果您在这里总结一下讨论，很明显REST不适合许多API，特别是当客户机-服务器交互本质上是有状态的时，就像对于非平凡的事务一样。对于客户端和服务器端，为什么要跳过所有建议的圈套，以便学究地遵循一些不适合问题的原则呢？一个更好的原则是为客户端提供最简单、最自然、最高效的方式来编写应用程序。

总之，如果你真的在你的应用程序中做了很多事务(类型，而不是实例)，你真的不应该创建RESTful应用程序接口。