REST vs. SOAP - Doesn't support Transactions?

Question

I'm barely examining the architecture of REST and SOAP as an SOA in my architecture. When comparing the two, I've heard one of the downsides to REST is that is doesn't support "Transactions" - what are they talking about? Because from I can tell, it does support CRUD operations just from the underlying HTTP protocols of GET, POST, DELETE, etc.

Can someone please elaborate? If I pick REST, can it support my transaction-intensive workplace of CRUD operations or is it better for me to go the SOAP-route?

Answer 1

If you need to do transactions across multiple calls, you will be better off not choosing either and picking something like remoting or doing binary serialization in wcf. Both REST and SOAP are meant to be stateless. A connection opens, performs an action and then closes again. That being said, wcf does support transactional support through SOAP, so if you have to choose just between the two that would be the one.

Answer 2

The kind of transaction you are referring to is a distributed transaction. This allows the client to perform multiple calls on the server (or even several different servers) and have them all commit or all rollback.

WCF supports distributed transactions through the WS-AtomicTransaction (WS-AT) protocol. This protocol is geared toward SOAP. Therefore, to use WCF transactions, you must use SOAP -- not REST.

Although you won't have across-call distributed transactions with REST, you can still use database transactions within a specific method. For example, you could implement a POST operation that submits an order and updates both the Order and OrderLine database tables in one transaction within that method. So, just because your application is transaction-intensive does not necessarily mean that the distributed kind of transactions which are a problem for REST are going to be important in your environment.