blocks|key|1737301|text|你必须使用你自己的“事务id”类型的tx管理。因此这将是4个调用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1737302|http://service/transaction+(some+sort+of+tx+request)
http://service/bankaccount/bob+(give+tx+id)
http://service/bankaccount/john+(give+tx+id)
http://service/transaction+(request+to+commit)|code-block|syntax|javascript|1737303|您必须处理操作在数据库(如果负载平衡)或内存中的存储，然后处理提交、回滚、超时。|1737304|在公园里不是真正的RESTful一天。|1737305|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

You'd have to roll your own "transaction id" type of tx management. So it would be 4 calls:

<pre><code>http://service/transaction (some sort of tx request)
http://service/bankaccount/bob (give tx id)
http://service/bankaccount/john (give tx id)
http://service/transaction (request to commit)
</code></pre>

You'd have to handle the storing of the actions in a DB (if load balanced) or in memory or such, then handling commit, rollback, timeout.

Not really a RESTful day in the park.

blocks|key|1737353|text|考虑一个RESTful购物篮场景。购物篮在概念上是您的事务包装器。与将多个商品添加到购物篮，然后提交购物篮以处理订单的方式相同，您可以将Bob的帐户条目添加到事务包装器，然后将Bill的帐户条目添加到包装器。当所有组件都就位后，您就可以POST/PUT包含所有组件组件的事务包装器了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1737354|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Consider a RESTful shopping basket scenario. The shopping basket is conceptually your transaction wrapper. In the same way that you can add multiple items to a shopping basket and then submit that basket to process the order, you can add Bob's account entry to the transaction wrapper and then Bill's account entry to the wrapper. When all the pieces are in place then you can POST/PUT the transaction wrapper with all the component pieces.

blocks|key|1737424|text|我认为，在这种情况下，在这种情况下打破REST的纯粹理论是完全可以接受的。在任何情况下，我都不认为REST中有任何东西表明您不能在需要依赖对象的业务案例中接触依赖对象。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1737425|我真的认为不值得为创建自定义事务管理器而跳过额外的障碍，因为您可以利用数据库来实现这一点。|1737426|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think that in this case it is totally acceptable to break the pure theory of REST in this situation. In any case, I don't think there is anything actually in REST that says you can't touch dependent objects in business cases that require it.

I really think it's not worth the extra hoops you would jump through to create a custom transaction manager, when you could just leverage the database to do it.

blocks|key|1522536|text|有一些重要的情况没有被这个问题回答，我认为这太糟糕了，因为它在Google上的搜索词排名很高:-)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1522537|具体地说，一个很好的恰当方法是:如果你发布了两次(因为中间的一些缓存发生了问题)，你不应该两次转移数量。|1522538|为此，您需要创建一个事务作为对象。这可能包含您已经知道的所有数据，并将事务置于挂起状态。|1522539|POST+/transfer/txn
{"source":"john's+account",+"destination":"bob's+account",+"amount":10}

{"id":"/transfer/txn/12345",+"state":"pending",+"source":...}|code-block|syntax|javascript|1522540|一旦你有了这个事务，你就可以提交它，就像这样：|1522541|PUT+/transfer/txn/12345
{"id":"/transfer/txn/12345",+"state":"committed",+...}

{"id":"/transfer/txn/12345",+"state":"committed",+...}|1522542|请注意，此时多个puts并不重要；即使是txn上的GET也会返回当前状态。具体地说，第二个PUT将检测到第一个put已经处于适当的状态，并返回它--或者，如果您试图在它已经处于"+committed“状态之后将其置于"rolledback”状态，您将得到一个错误，并返回实际提交的事务。|1522543|只要您与单个数据库或具有集成事务监视器的数据库通信，这种机制实际上就会工作得很好。您还可以为事务引入超时，如果您愿意，甚至可以使用Expires头来表示。|1522544|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|X|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|Z|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

There are a few important cases that aren't answered by this question, which I think is too bad, because it has a high ranking on Google for the search terms :-)

Specifically, a nice propertly would be: If you POST twice (because some cache hiccupped in the intermediate) you should not transfer the amount twice.

To get to this, you create a transaction as an object. This could contain all the data you know already, and put the transaction in a pending state.

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

{"id":"/transfer/txn/12345", "state":"pending", "source":...}
</code></pre>

Once you have this transaction, you can commit it, something like:

<pre><code>PUT /transfer/txn/12345
{"id":"/transfer/txn/12345", "state":"committed", ...}

{"id":"/transfer/txn/12345", "state":"committed", ...}
</code></pre>

Note that multiple puts don't matter at this point; even a GET on the txn would return the current state. Specifically, the second PUT would detect that the first was already in the appropriate state, and just return it -- or, if you try to put it into the "rolledback" state after it's already in "committed" state, you would get an error, and the actual committed transaction back.

As long as you talk to a single database, or a database with an integrated transaction monitor, this mechanism will actually work just fine. You might additionally introduce time-outs for transactions, which you could even express using Expires headers if you wanted to.

blocks|key|1737601|text|如果您在这里总结一下讨论，很明显REST不适合许多API，特别是当客户机-服务器交互本质上是有状态的时，就像对于非平凡的事务一样。对于客户端和服务器端，为什么要跳过所有建议的圈套，以便学究地遵循一些不适合问题的原则呢？一个更好的原则是为客户端提供最简单、最自然、最高效的方式来编写应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1737602|总之，如果你真的在你的应用程序中做了很多事务(类型，而不是实例)，你真的不应该创建RESTful应用程序接口。|1737603|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you stand back to summarize the discussion here, it's pretty clear that REST is not appropriate for many APIs, particularly when the client-server interaction is inherently stateful, as it is with non-trivial transactions. Why jump through all the hoops suggested, for client and server both, in order to pedantically follow some principle that doesn't fit the problem? A better principle is to give the client the easiest, most natural, productive way to compose with the application.

In summary, if you're really doing a lot of transactions (types, not instances) in your application, you really shouldn't be creating a RESTful API.

blocks|key|1522648|text|我相信这将是使用在客户端上生成的唯一标识符的情况，以确保连接问题不暗示由API保存的重复性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1522649|我认为将客户生成的GUID字段与transfer对象一起使用，并确保不会再次插入相同的GUID，将是解决银行转账问题的一种更简单的解决方案。|1522650|不了解更复杂的场景，例如多个机票预订或微架构。|1522651|我找到了一篇关于这个主题的论文，讲述了dealing+with+the+transaction+atomicity+in+RESTful+services的经历。|offset|length|1522652|entityMap|0|LINK|mutability|MUTABLE|url|http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf^0|0|0|0|J|1M|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@$H|V|I|W|1|X]]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

I believe that would be the case of using a unique identifier generated on the client to ensure that the connection hiccup not imply in an duplicity saved by the API.

I think using a client generated GUID field along with the transfer object and ensuring that the same GUID was not reinserted again would be a simpler solution to the bank transfer matter.

Do not know about more complex scenarios, such as multiple airline ticket booking or micro architectures.

I found a paper about the subject, relating the experiences of <a href="http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf" rel="nofollow">dealing with the transaction atomicity in RESTful services</a>.

I'm wondering how you'd implement the following use-case in REST. Is it even possible to do without compromising the conceptual model?

Read or update multiple resources within the scope of a single transaction. For example, transfer $100 from Bob's bank account into John's account.

As far as I can tell, the only way to implement this is by cheating. You could POST to the resource associated with either John or Bob and carry out the entire operation using a single transaction. As far as I'm concerned this breaks the REST architecture because you're essentially tunneling an RPC call through POST instead of really operating on individual resources.

Transactions in REST?

数据库

服务器

我想知道您如何在REST中实现以下用例。有没有可能在不影响概念模型的情况下做到这一点？读取或更新单个事务范围内的多个资源。例如，将100美元从Bob的银行帐户转到John的帐户。据我所知，实现这一点的唯一方法是作弊。您可以发布到与John或Bob关联的资源，并使用单个事务执行整个操作。就我而言，这打破了REST架构，因...

问REST中的事务？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问REST中的事务？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问REST中的事务？
EN