Many people make the choice between these two methods for sending form data to the server for the wrong reasons. Some people think that they should always use POST because it is more secure (which is completely untrue as it is no more secure than GET is). Others use POST because it avoids cluttering the URL (which is true but not a good reason for using it).
With some browsers if a form was sent using POST and the person using the browser uses their back button to go back to the page the form was POSTED to then the browser annoyingly asks if you want to reprocess the POST data. To avoid this problem some people write their form processing to use POST then redirect then GET so that using the back button skips past the POST step while others simply write their POST processing so that running it more than once will make no difference (in which case the person can happily say yes to reloading the page). Where the author doesn't do either of these then reloading the page may result in unwanted processing taking place and since the person accessing the site likely doesn't know whether the processing has been properly written to avoid duplication or not this just makes things more difficult for them. For those whose browsers don't display this message and where the POST processing is not set up to allow rerunning or to bypass it then using back will corrupt the data.
Using GET avoids all of the problems of messages when using the back button and it also avoids any issues of rerunning server side processing and so some people use GET as a way to avoid the back button issues with POST. This is another inappropriate reason for choosing between them.
In selecting between GET and POST you need to completely forget about how each passes their data to the server as in each case the data being passed is just as accessible and the method used to pass the data could be changed without affecting the way GET and POST work.
What you do need to consider in deciding which to use is the type of request you are making. If your request is to retrieve data then the appropriate method to use is GET. When you use a GET request you are telling the browser that your request is not going to update anything on the server. Using GET gives the browser permission to cache the result from the first time you do the GET call so that if the same GET call is made again the browser can simply redisplay the cached copy of the page without needing to retrieve the page from the server again. Some people see this as a problem with GET and perform all sorts of manipulations to try to force the browser to retrieve the page from the server again instead of using the cached copy. The correct way of doing this which they overlook is to not use GET (which you shouldn't be using if the data is supposed to be changing).
GET as its name implies is supposed to be used for data retrieval from the server. The most obvious application of this is for any search query form. The use of GET implies that the data on the server is not being changed and that if the same call is repeated that the cached copy of the page is allowed to be displayed.
POST implies that you might be changing the data stored on the server. The browser is not allowed to assume that the data after one such call will be the same as it was on a previous call using the same POST field values. When you write a POST request it is up to you to ensure that you either code it so that the same request can't run twice or that if it does that the data isn't changed when it runs a second time. Even using POST redirect GET by itself is not sufficient to do this as browser glitches can cause the same form to be submitted twice - even some financial institutions don't get this right and can end up processing the same payment twice rather than recognising that the second occurrence is almost certainly an unwanted duplicate.
So it isn't just a matter of the correct choice of POST or GET, you also need to make sure that your processing is appropriately written so that your GET calls can assume the same data when the same call is made multiple times and that your POST calls only update the data once if the same data is sent multiple times. When processing the same data multiple times might be legitimate then your script should ask for confirmation of the duplicate in that situation. If you don't take these things into account then your forms will not work correctly for all of your visitors.
This article written by Stephen Chapman, Felgall Pty Ltd.