Avoid duplicate POSTs with .NET Core

Question

I'm using POST in a .NET Core REST API to insert data on database.

In my client application, when the user clicks a button, I disable this button. But sometimes, because some reason, the click of the button may be faster than the function of the disable button. This way, the user can double click on the button and the POST will be sent twice, inserting the data twice.

To do POST I'm using axios on the client side. But how can I avoid this on the server side?

Answer 1

Handling concurrency with inserts is hard, frankly. Things like updates and deletes are relatively trivial as you can use concurrency tokens. When doing an update for instance, a WHERE clause is added to check the row that is about to be updated concurrency token value. If it doesn't match, that means it was updated since the data was last queried, and you can then implement some sort of recovery stategy.

Inserts don't work the same way because there's obviously nothing there yet to compare to. Your best bet is a somewhat convoluted strategy of assigning some id to a particular insertion. This will have to be persisted on a column in your table, and that column will need to be unique. When you display the form, you set a hidden input with a unique-ish value, such as Guid.NewGuid(). This will then be posted back when the user submits. This then gets added to your entity, and when you save it will be set on the row that's created.

Now let's say the user double-click the submit button firing off two nearly simultaneous requests. Because the same form data is being submit for both requests, the same id is present in both submissions. The one that makes it first ends up saving the record to the database, while the next will end up throwing an exception. Since the column the id is being saved to is unique, and the same id was sent for both requests, the second one will fail to save. At this point, you can catch the exception and recover some how.

My personal recommendation is to make it seamless to the user. When you hit the catch, you query the row that was actually inserted with that id, and return that id/data instead. For example, let's say this was for a checkout page and you were creating orders. You're likely going to redirect the user to an order confirmation page after completion. So, on the request that fails, you look up the order that was actually created, and then you just redirect to the order confirmation page immediately with that order number/id. As far as the user is concerned, they just went to directly to the confirmation page, and your app ended up only inserting one order. Seamless.