I am designing an application that works with REST API requests for dealing with information stored in a database.

The user will add, edit, delete information in this client and after SAVE the information will be rolled out to the server (database) with the corresponding API request (GET, POST, PUT, DELETE)

Now I have the situation where the user can delete an element, let's call it a product and can be deleted from a grid. I want when the product is deleted to disappear from the grid. Then the user hits SAVE and via an API request the product is really deleted from the DB.

But the product can be deleted only when there are no transactions on it (e.g. no sales, purchases). For this there is a constraint in the database and the API request would return an error in this case.

So, if this (error) happens the SAVE should be cancelled and the product should "re-appear" in the grid. Right? And here's where I am having problems wrapping my head around.

How to coordinate this? Is this the way to go (re-appearing on the grid)? It sounds un-intuitively for the user. What if the user deleted multiple things and suddenly re-appear?

To prevent of a logic making something re-appear on the grid I am thinking when the user deletes it, to call then the API with the DELETE method in a "rollback" transaction. If it returns the constraint error then to show an error message directly at that moment, otherwise then to make the product disappear.

Is this something that is normally done in this case? If not, how to treat this situation?

NOTE: Because of the SAVE button I plan to implement running all API requests when hitting SAVE inside a "Transaction". The UI will request a transaction via another API request, run all other API requests and if no error then run commit otherwise rollback (via API). I know this goes against the "stateless" characteristic of REST but is the only way I can think of to deal with a SAVE button. Is there any other approach that can be used for this?

Help appreciated..

2 Answers 2


Here's another way of approaching this:

The data used to build the grid could include flags that denote whether each item can be deleted so if, for example, there were outstanding transactions on an item, the User should not be allowed to even try to delete it from the grid in the first place.

OK, you could still have an issue if Transactions come and go in real time, but your "Big SAVE Button" logic would need to handle this anyway.

As far as cleaning up the mess after a failed "Save" goes, it's perfectly reasonable for an application to

  • Put up a dialog saying "Oops! Your save didn't work.",
  • Wait for the User to click "OK", and
  • Reload the entire grid.

Bonus: the code you need to do that reload [very] probably already exists!

  • Thank you very much for your reply, it has been very useful. To have a flag on the grid indicating if can delete is a good idea, it is sort of similar to the idea of the "DELETE in a rollback" I explain above. The table of products has actually a hierarchy of 6-8 tables until it displays the constraint. So for that flag you mention I would have to query those 6-8 tables first to see if there is any constraint. I will evaluate both options. Thanks for the "permission" for making things re-appear in the grid :) , this was what was bothering me and I didn't know if it was a good approach.
    – jav
    Commented Dec 15, 2020 at 7:13
  • I will give it a thought to what was discussed here talk with the developers and let you all know what we did..
    – jav
    Commented Dec 15, 2020 at 7:14

A better option would be to use ajax and call the delete when it happens and remove the record on success or show an error message. If you must have a save button, then I would have a single POST that handles everything. Trying to track all actions and call the respective endpoints all at once on the client side and manage that as a transaction is overly complicated and creates far more edge cases to handle. Do not try to manage a database transaction on a client, it will cause massive problems with hanging transactions.

This is the reason sending multiple requests on save is a bad idea, lets say you have 5 changes to save. You have to wait for 5 round trips, even concurrently that is 5x as much chance of network failure. Those 5 requests all have boilerplate overhead, and likely some state information to relate them together, so it's inefficient in data usage. This also creates an easy DOS potential that may be entirely non malicious, if a user makes a lot of changes and then saves the sudden spike in traffic could be an issue. If you happen to need to rollback all changes if any of those 5 fail, you now have to keep track of that rollback info (even if it's never used most of the time) and hope your user doesn't close the browser before everything comes back successful, or you might fail to rollback changes.

  • Thank you very much for the answer. I have understood all you said. I might have to reconsider the transaction idea. Removing the SAVE button is unfortunately not an option. Let's say I put everything in a big POST after the SAVE. That is not really a problem. But what happens before hittinng the SAVE button when the user deletes a product? It will disappear from the grid. If the big POST after the SAVE fails. Should I make that product re-appear in the grid, right ? NOTE: For more info my client application is a Windows WPF application, not a web application, the server runs on Linux.
    – jav
    Commented Dec 14, 2020 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.