CODEWITHSUNDEEP
.netasp.net-web-api
Vadiya
Vadiya

Reputation: 111

How to handle duplicate posts requests in web api

I have a scenario where User enters all his details in a Form and clicks Submit (Post request) in Asp.Net Web api. What if the user clicks the Post button twice. How do I handle the request.

Any one please answer this question.

Upvotes: 2

Views: 8978

Answers (2)

matt_lethargic
matt_lethargic

Reputation: 2796

I completely disagree with @keysl, if you're creating an API you should probably be thinking of making it RESTFul and rest services should be idempotent, take a read of this article perhaps:

"In the context of REST APIs, when making multiple identical requests has the same effect as making a single request"

UPDATE

The effect POST has is the same, a new record is created! If there is a uniqueness constraint then you should return the correct status code, for instance 400. In the API's I work on we would return 400 and a JSON object with information of why validation/verification failed.

If the API is public then this is all you can do, you can't be held responsible for what people hit your API with. I work on a public API with well over a thousand endpoints and we do not worry about the user submitting data twice by accident, we just validate for uniqueness.

If this question is asking about a private endpoint that back a website then I totally agree with the disabling of the submit button, but you still should be using validation in the back end API and the front end should handle the returning of 400 gracefully.

While what @keysl is saying are all valid things (except DTOs are POCOs, thats just weird thing to say) I think points 1, 2 and 4 don't relate to the question at all and view models have nothing to do with a user clicking the button twice!

Upvotes: 4

keysl
keysl

Reputation: 2167

This is something you should'nt cocern about if you use view models But since this is api things should are little bit complicated.

You can argue @sm that disable submit button when the user submit a request, but if you are shipping a pure api and you are not responsible for the consumer. Then it's out of the question

Things that we do in our office are the ff.

  1. Tokenized Handshake. Each POST,PUT,PATCH,DELETE Request (Almost Any non GET Request) Should get a token from the server before accessing the API endpoint. In this part you can check how many times the user has requested a token to use. This is complicated but you can track the user's activity. You can also set threshold of request and ban the user if it exceeds the reasonable request a human can send without intent of breaking your api.

  2. Use a secret special Header Attribute. If you are shipping api that is for private commercial use, Use a secret headers key and give the cred to trusted party that will consume your api.

  3. Different Model for GET and POST. And for god's USE DTO instead of using the POCO class directly at your action method

  4. I don't quite familiar but our DEVOps ensure that if we are shipping a public api. There should be a DDOS Filtering configuration made in your IIS prod environment.

Upvotes: 3

Related Questions