Eric Newcomer On Difference Between RESTful vs. Web Service Transactions

| by Dilip Krishnan Follow 0 Followers on Mar 18, 2009. Estimated reading time: 1 minute |

Eric Newcomer, chair of the OSGi Alliance Enterprise Expert Group and former CTO of IONA Technologies, posted an answer to the question “What is the difference between RESTful transactions and Web Services transactions?”

Eric sets the context by differentiating transactions into local and global transactions, saying that local transactions are not particularly interesting as they work the same way in both cases.

The question therefore really pertains to global transactions -- those that involve more than one database, potentially on different computers -- since that's where things are very different.

He warns that since Web services are a technology, and REST is an architectural approach the comparison might not be accurate. However he attributes the differences in implementations of transactions to the different assumptions arising from the underlying infrastructure, especially related to distributed access to shared data, or shared state.

Web services transactions ([…]WS-Transactions[…]) are intended to be compatible with existing TP [Transaction Processing] infrastructures. The REST approach, on the other hand, evolved from the Web.

As a result he states that the key differences between the two types of transactions are based on:

1. How the transactions are coordinated among participating systems

For compatibility with existing shared state mechanisms, Web services transactions propagate shared transactional context among participants in a global transaction so that each participant's access to shared state can be coordinated with the others. REST based transactions assume that only one party to a global transaction accesses the shared state at any given time, sort of like passing a token. […] They are responsible only for knowing what they must do when they receive the shared state – when it's their turn.

2. How the systems handle transaction failure and recovery

RESTful systems require a very different design for handling failure and recovery, since it cannot be automated, the trade off in additional application level design and coding pays results in a system better suited to the assumptions of the Web.

Be sure to check the original article.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you