I am going to assume that when you talk about transactions you are talking about a distributed Two Phase Commit protocol.
If I understand correctly you are trying to understand how we could ever use REST to perform operations that span multiple systems if REST cannot support transactions across distinct REST requests. The problem is you are making a potentially flawed assumption that we should be using transactions to achieve consistency. What price are we paying for using them, and what alternatives exist?
Pat Helland who used to work for Amazon and is now at Microsoft, wrote a paper Life beyond Distributed Transactions. In the paper the Author makes the following statement:
Unfortunately, programmers striving to
solve business goals like eCommerce,
supply-chain-management, financial,
and health-care applications
increasingly need to think about
scaling without distributed
transactions. They do this because
attempts to use distributed
transactions are too fragile and
perform poorly.
His paper explores alternative solutions to distributed transactions that do scale and perform well.
Maybe REST will be successful because it does not support transactions. Here is a quote from Roy Fielding, the guy who invented the term REST
If you find yourself in need of a
distributed transaction protocol, then
how can you possibly say that your
architecture is based on REST? I
simply cannot see how you can get from
one situation (of using RESTful
application state on the client and
hypermedia to determine all state
transitions) to the next situation of
needing distributed agreement of
transaction semantics wherein the
client has to tell the server how to
manage its own resources.…for now I consider “rest
transaction” to be an oxymoron.
This is from a message on the REST-discuss list from June 9th, 2009. I can’t provide a link because Yahoo groups is useless.