Search forms that use the POST HTTP method are a shabby Web development practice that I run into every day. Here’s the number one reason why using POST on search forms is a bad idea:
That’s what users see when they hit the back button to return to search results that were produced using a POST request. When the back button is going to take you to a page that was requested using the POST method, this warning appears in order to prevent you from sending duplicate information to the Web server. This is important if the form you submitted charged your credit card for $100 or posted a new entry to your blog. It is never, ever useful if you’re just searching for information.
This bad practice is made worse by the fact that people are most likely to use the back button when they are navigating search results. They click on one item, find that it’s not what they need, and then click on the back button to get back to the results.
A second problem with POST is that you can’t bookmark the results of a POST request. Sometimes it’s useful to bookmark search results, and the only way to facilitate that as a developer is to use GET.
I think the problem is that many programmers don’t really know the difference between GET and POST, or they know just enough to be dangerous. There’s been a lot of talk about the dangers of GET, with good reason. You should never use GET (and remember, regular old
a href links are GET requests) for any operations that will change data on the server. “Cancel my account,” “delete this entry,” and “place my order” should all use POST. Unfortunately, some developers have taken this to mean that one should never use GET with a form.
GET and POST both have their place, and if you’re a Web developer you should understand the pros and cons of each of them. Or if you’re too lazy to do that, just remember that search forms should use GET. Your users will appreciate it.