1

The product I have is using Spring Data REST, and wishes to follow its architecture to the teeth, but the product is required to handle updates on n resources, as a single operation by the user. In a scenario like this, we have to think, that in case we have trouble in the nth update operation, and to rollback, user would have to backup all to-be-updated data, in case of such a trouble, and update all n-1 resources back with this backup data. There is also the possibility that during rollback we might have another trouble, and whole rollback might fail, causing many problems.

How can all these be handled properly by the user without abandoning the RESTful CRUD endpoints of Spring Data REST (meaning not to create custom batch endpoints to break architecture)?

My question is to get ideas on how to safely handle above scenario as the user of an uncustomized Spring Data REST product.

buræquete
  • 14,226
  • 4
  • 44
  • 89

1 Answers1

0

I think this answers your question regarding making the controller endpoints transactional, however if you want arbitrarily related updates to be transactional, you aren't really talking about a RESTful API.

Michael Hibay
  • 522
  • 3
  • 11
  • I agree, that is why my question was focused not to modify Spring Data REST and its architecture by adding custom controller etc, but how to manage the scenario I've given for the user of such a RESTful product. – buræquete Jul 26 '17 at 03:36
  • The short answer is the user doesn't. It's a bad design. Spring Data REST is a very opinionated tool which wants to be used in as a CRUD API. To add the functionality you want in a way which is useful to the user means to add collection interactions within Spring Data REST, not break the tools paradigm to try to one-off a solution. – Michael Hibay Jul 26 '17 at 13:51