Check if can delete before save

Question

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..

Answer 1

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!

Answer 2

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.