The POST method is vastly overused in HTML forms, with negative consequences for the user experience. POST requests cannot be bookmarked, linked to, indexed, searched, or cached. For example, recently I wanted to link to a list of top independent albums from RIAA Radar. However I couldn’t becuase the search request was sent via POST. The URL was http://www.riaaradar.com/search.asp, but there was nothing in the URL to indicate whether I was searching for Black Box Recorder or Britney Spears.
All safe requests should be done with GET. GET is vastly friendlier to users and dramatically improves your search engine placement. (In fact, form results sent with POST might as well be invisible to search engines.) POST should only be used for requests that cause some action to be taken: a book to be ordered, a page to be printed, a contract to be signed, etc. Search results and many other things don’t fall into this category.
I later discovered that there are URLs for the searches I was trying at RIAA Radar that do include all relevant information in the URL so I can link to them. However the fact remains that at least one form on their site specifies POST for search requests. Out of curiosity I saved a local copy and changed the method to GET. Wouldn’t you know it? The form worked. That is, their specific server side script accepts the same requests via GET or POST.
This dual method approach is a common antipattern in web apps. You should never have the same script that blithely accepts the same parameters via GET or POST and returns the same value. The script should pick one and stick to it. If the script is safe, then use GET. If the script is unsafe (i.e. has side effects) use POST. However it is not appropriate to pick both. That either loses search engine juice and linkability (using POST where GET is called for) or opens security holes (using GET where POST is called for).
On rare occasions you will see a script that does different things when invoked via GET or POST. For instance, a GET to http://www.example.com/forums/birds might return an index page showing the current posts in the forum, while a POST to that page might add a new entry in the forum. However, a different script is used (or at the very least a different action is taken) and different parameters are sent depending on whether a GET or POST is sent to that URL. It would still be wrong if one could add the POST’s parameters to the URL’s query string, and thereby add a new entry in the forum.
Many sites still tell you, incorrectly, that whether to use GET or POST has something to do with how much data you’re sending. That’s false. It’s a statement based on bugs in early browsers that hasn’t been true any time this millennium. Choosing GET or POST has nothing to do with how much data you’re sending and everything to do with whether you want readers to be able to find you. GET allows bookmarks, links, and search engine placement. POST doesn’t. It’s as simple as that.