Why you should use POST, redirect, GET - Trickcode

google

If you’ve spent your life developing using ASP.NET WebForms then you may not be familiar with the HTTP verbs. The HTTP protocol contains a number of verbs. The four that make HTTP restful are:

• GET – retrieve
• DELETE – delete
• POST – create
• PUT – update

Three of these (GET, DELETE and PUT) are idempotent which means that repeating the request is safe. POST is non-idempotent which is why it is used for actions such as inserting records into a database or billing a credit cards. As a general rule you don’t want those actions to be repeated. It’s also why your browser prompts you when you refresh a page that was requested using POST.

Note: Very few browsers support DELETE or PUT so POST is used instead.

Unfortunately web browsers have a refresh button and people like to use it. While refreshing a page that displays the details about a book might be harmless doing the same thing to a page that submitted credit card details could cause the user to be billed a second time.

To help prevent this developers often use the POST, redirect, GET design pattern that you’ll see in a lot of ASP.NET MVC examples. With this design pattern the first action is requested using POST. If that action is successful it redirect the user to a second action which is requested using GET. This way if the user presses the refresh button on their browser the second action is repeated rather than the first.

Let’s look at a real world example using payment processing. The user fills out a form which uses POST to send data to /payment/process. If there is an error it can redisplay the original form allowing the user to make changes. Any attempt to refresh the page is safe because it should also fail and redisplay the original form. Once the user has successfully completed the payment they would be redirected to /payment/receipt/NUMBER which displays the receipt to the user. If they click on the refresh button the browser repeats the GET request for /payment/receipt/NUMBER which causes the receipt to be re-displayed without repeating the transaction.

Note: Users can still accidentally post data twice using the back button. If you were developing a shopping cart application then don’t solely rely on the POST, redirect, GET design pattern. You should implement a mechanism to prevent the user from re-posting the same data twice