[ACCEPTED]-If transactions over REST are unachievable, how can REST ever be really useful?-standards

I am going to assume that when you talk 41 about transactions you are talking about 40 a distributed Two Phase Commit protocol.

If I understand 39 correctly you are trying to understand how 38 we could ever use REST to perform operations 37 that span multiple systems if REST cannot 36 support transactions across distinct REST 35 requests. The problem is you are making 34 a potentially flawed assumption that we 33 should be using transactions to achieve 32 consistency. What price are we paying for 31 using them, and what alternatives exist?

Pat 30 Helland who used to work for Amazon and 29 is now at Microsoft, wrote a paper Life beyond Distributed Transactions. In 28 the paper the Author makes the following 27 statement:

Unfortunately, programmers striving 26 to solve business goals like eCommerce, supply-chain-management, financial, and 25 health-care applications increasingly 24 need to think about scaling without distributed transactions. They 23 do this because attempts to use distributed transactions 22 are too fragile and perform poorly.

His 21 paper explores alternative solutions to 20 distributed transactions that do scale and 19 perform well.

Maybe REST will be successful 18 because it does not support transactions. Here 17 is a quote from Roy Fielding, the guy who 16 invented the term REST

If you find yourself 15 in need of a distributed transaction protocol, then how 14 can you possibly say that your architecture 13 is based on REST? I simply cannot see 12 how you can get from one situation (of 11 using RESTful application state on the 10 client and hypermedia to determine all 9 state transitions) to the next situation 8 of needing distributed agreement of transaction 7 semantics wherein the client has to tell 6 the server how to manage its own resources.

...for 5 now I consider "rest transaction" to 4 be an oxymoron.

This is from a message on 3 the REST-discuss list from June 9th, 2009. I 2 can't provide a link because Yahoo groups 1 is useless.

If you want transactions in a ReST application, at 29 the ReST API function, it's usually because 28 you still have your techie webservice guy 27 googles on.

Let's look at it another way.

Soap 26 googles on: Open a transaction, create a 25 customer record, create an order record, commit 24 transaction.

ReST googles on: Ask server 23 what to do. Server says "create customer 22 resource", so POST /customers. Server says, "now 21 create an order if you want", client creates 20 the order by following the form.

In ReST, the 19 application protocol is expressed in terms of resources being 18 created and manipulated, not in terms of 17 data that has transaction boundaries.

If 16 you want to have a long-running transaction 15 that spans all those operations, it's the 14 server that decides to initiate it, not the client.

You 13 can still implement long running transactions 12 on the server side. If you attempt to want 11 transactions from the client side, then 10 you assume the client already knows all 9 the operations it's going ot execute and 8 the transaction boundaries that exist between 7 those operations. If that's what your expectations 6 are of the client, you've already given 5 up the late binding, hypermedia-driven nature 4 of a rest architecture.

So indeed, if you're 3 not doing ReST and are trying to fit in 2 RPC over http, you'll have a problem with 1 not having transactions.

I think most actions that normally require 12 transactions can be reworked to occur without 11 them.

For example, the classic bank transfer. Suppose 10 I want to move $100 from account A to B:

Begin Transaction
  /Debit  A, $100  
  /Credit B, $100
Commit Transaction

This 9 could be reworked as:

 /Transfer  A, B, $100  

In this way, the server 8 might do this in two steps, but the action 7 from the client is a single, atomic operation 6 that makes logical sense.

I'm sure there 5 are lots of examples where it is more convenient 4 to do an all or nothing set of operations 3 (and I'm curious what people can come up 2 with to address them), but I usually rework 1 things in this way.

A REST operation can start a transaction, perform 14 multiple database or other transactional 13 operations, then commit or rollback - all 12 within the scope of a transaction.

What REST 11 cannot do is to be other than the root of 10 a transaction. You can't start a transaction, then 9 perform two REST operations and a database 8 operation, then commit them all together. That's 7 just like the situation of ASMX web services 6 in .NET. They can be the root of a transaction, but 5 that's all. They were successful for years, until 4 WCF was introduced, supporting WS-Transactions. Even 3 today and using WCF, most web service operations 2 do not need to be transactional in the sense 1 you're asking about.

This is an interesting topic. As you mentioned, SOAP 16 has this sort of functionality already, but 15 it took many years before SOAP matured to 14 the point where people would consider doing 13 real security and transactions with it. Before 12 that, it was CORBA.

The various high-grade 11 extensions to SOAP, including security and 10 transactions, took a lot of work by a lot 9 of people to get them right. This isn't 8 going to happen to REST overnight, and it 7 may never happen at all.

I feel that much 6 of REST's currently popularity is something 5 of a backlash against poorly-designed and 4 over-complicated SOAP implementations, which 3 is a shame, because SOAP doesn't have to 2 be like that. As with anything else, it 1 needs good design to make it work nicely.

Take a look at the OpenStreetMap API. I think it is kind 3 of "REST" and it provides kind 2 of "transactions" – called 'changesets' there. Is 1 that what you need?

Actually, transactions in REST work in much 65 the same way that transactions are supposed to work in traditional 64 SOAP services.

RPC-style transactions, where 63 the client issues a "begin transaction" command 62 (or some operation that implicitly begins 61 but does not commit a transaction), followed 60 by some additional operations, followed 59 by another implicit/explicit "end transaction" command, are 58 antiquated. The Web Service world moved 57 away from the RPC model a long time ago; RPC/encoded 56 in SOAP is not even WS-I compliant!

Instead 55 of procedures, SOAP services today are built around 54 the concept of messages. A single message contains 53 all of the information necessary to perform 52 a complete transaction. If you are submitting 51 an order, the OrderRequest message will contain the 50 customer information, order information, order 49 details, payment details... everything that 48 the server could possibly need to know about 47 a single order.

We do have WS-Transactions 46 that define semantics for distributed transactions, but 45 these aren't really intended to support 44 RPC-like semantics from the client, they're 43 meant for orchestrations when you need to 42 have several services participate in the 41 same transaction. For example your order 40 service needs to enlist a payment processing 39 service to validate the credit card info 38 and post a payment, which needs to be rolled 37 back if the fulfillment service finds that 36 you're out of stock, or something like that... you 35 get the idea. This all takes place in the 34 server environment so there's really nothing 33 stopping you from doing the same thing in 32 REST.

In REST, you have resources instead of messages, but 31 the concept is really quite similar. Instead 30 of an OrderRequest message the client submits (PUT) an 29 Order resource, and the resource should contain 28 all the same information necessary to complete 27 the transaction. Admittedly, if you're 26 trying to perform complex orchestrations, you 25 might find REST a bit unwieldy compared 24 to SOAP, but that doesn't mean you can't 23 keep using REST for your front-end, just that SOAP 22 will serve you better for your back-end services.

The 21 reality, though, is that 99% of the time, people 20 don't need the complexity of WS-Transactions. I 19 know this because I use SOAP (WCF) almost 18 exclusively and rarely use WS-Transactions.

In 17 REST, the "state" resides on the client. The 16 server tells the client, "here is all the 15 information you need to give me to create 14 this resource (complete this transaction)." But 13 this blank form doesn't actually begin a transaction. It's 12 up to the client to actually provide the 11 information - fill in the form, so to speak. What 10 the client does while it is filling in the 9 form is of no concern to the server; when 8 the client finally sends the finished form 7 to the server, it is validated in its entirety. It's 6 similar to a Unit of Work, except that the 5 client is the one keeping track of the "work".

Hope 4 this gives a better idea of how transactions 3 can be and are achieved over REST. They just 2 rely on a richer message/resource concept 1 and a form of optimistic concurrency.

Because not every system requires transactions.

0

I think that transactions using REST are 31 actually achievable. Think of a transaction 30 as a resource which you can create (start), edit 29 (post changes through), and delete (commit, roll 28 back). Changes posted to the transaction 27 wouldn't need to modify the global state 26 until the transaction was committed, and 25 during the commit, you could enforce any 24 global state consistency rules you'd need 23 to. The transaction resource would, of 22 course, be protected through authorization 21 rules.

You already mentioned the common illustration 20 for this concept:

Now, I've read a specific 19 argument a couple of times in my research, and 18 its related to how we're supposed to think 17 about transactions in REST, and the example 16 given is the shopping cart, where you implicitly 15 have isolation because the cart is YOURS.

However 14 I disagree with this argument, firstly, the 13 isolation a shopping cart has is merely 12 convenient, this isn't a transaction isolation.. what 11 happens if I'm simultaneously doing an operation 10 against my cart whilst some part of my application 9 is reading data from it? I wouldn't expect 8 the reading part of my application to see 7 data that is 'still in transaction'.

Why 6 wouldn't you allow the viewing of the transaction? As 5 long as you present it as what it is, a 4 list of pending changes, it's actually helpful 3 to provide that feature. But if you didn't 2 want it to be viewable, you could disabling 1 GET on the resource.

I know of very successful online accounting 12 systems (SaaS) which have a REST-based non-transactional 11 API for creating, retrieving and manipulating 10 invoices etc. They are widely acclaimed 9 for their API and the ease of integration 8 their system with other parties. The API 7 is easy to maintain, usable from a variety 6 of platforms and ensuring backwards compatability 5 is reasonably straightforward.

The lack of 4 transactions can be a real pain in the neck, but 3 most of the time, when their servers aren't 2 too loaded, the API works very well.

Sometimes, less-than-perfect 1 is just good enough.