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?