1

We expose REST services which can expose POST, PUT, GET and DELETE operations. Consumers often design there UI in such a way that the user with a single click can create, update and delete. If they send us three calls for PUT POST and DELETE, then it is possible that one of them might fail and cause data inconsistency. Currently we create a wrapper service which allows them to call one service which calls all the three operations and we guarantee a transaction with JBOSS transaction controls, so if one operation fails then the all transactions are rolled back.

Is there are better way of handling this, which can help us avoid creating these wrapper service?

Raghav
  • 189
  • 10

1 Answers1

1

Short answer: no, there is not.

You are looking for "transactions" support for your REST services. There are a lot of online material (no out-of-the-box solution though), including this exact question: Transactions in REST?.

I think it is important to note that the concept of transactions is somewhat in conflict with the concept of a stateless distributed system. There are some people working on getting transactions into REST (https://www.atomikos.com/Blog/TransactionsForTheRESTOfUs, http://www.jboss.org/reststar/specifications/transactions.html), but in general the solution is to design the system in a way that does not require distributed transactions.

Exporting DB record operations directly as CRUD operations is the culprit most of the time. If you're doing this, just try to come up with resources that have actual meaning for the client, you will find that most of your problems disappear.

As a sidenote, working for financial institutions, the classical example of needing transactions for transferring money from one account to another is pretty oversimplified. It does not work that way in real life, and a lot (including some forms of actual money transfer) is NOT transactional in this sense.

Community
  • 1
  • 1
Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38