REST vs SOAP - doesn't support transactions?

Question

I hardly see REST and SOAP architecture as SOA in my architecture. When comparing the two, I heard that one of the drawbacks of REST is that it does not support "Transactions" - what are they talking about? Because, as I can say, it only supports CRUD operations from the main HTTP protocols GET, POST, DELETE, etc.

Can anyone comment? If I choose REST, can it support my time-consuming CRUD operations workstation or is it better for me to go along the SOAP route?

Answer 1

To quote Roy Fielding from yesterday

I believe that the "transaction of rest" is an oxymoron.

Answer 2

If you need to make transactions across multiple calls, you would be better off not picking and collecting something like deleting or doing binary serialization in wcf. Both REST and SOAP must be stateless. The connection opens, performs the action, and then closes again. At the same time, wcf supports transactional support through SOAP, so if you only need to choose between two that will be like that.

Answer 3

The type of transaction you are referring to is a distributed transaction. This allows the client to make several calls on the server (or even on several different servers), as well as make them or roll back completely.

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

Although you will not have distributed transactions through REST, you can still use database transactions as part of a specific method. For example, you can implement the POST operation, which sends an order, and updates the Order and OrderLine database tables in a single transaction as part of this method. Thus, just because your application is heavily connected with transactions does not necessarily mean that the distributed types of transactions that are a problem for REST will be important in your environment.

Answer 4

Take a look at RETRO .