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.
December 26, 2007 at 3:29 pm
“Pros and cons” is really the wrong term. That’s like saying you should understand the pros and cons of using a hammer vs a screwdriver. They are different tools, and in most situations, only one is the correct choice.
As a user, btw, you can use the frmget bookmarklet to fix that sort of brain damage. It only works if the server accepts query parameters in the URI via
GETjust as well as in the request body viaPOST, but (another sign that people’s understanding ofPOSTvsGETis sloppy) most do.December 26, 2007 at 3:41 pm
I think the common indifference to parameters being in GET or POST is less to do with anyone’s lack of understanding of GET vs. POST and more to do with the fact that virtually every library for decoding request parameters is indifferent to whether the parameters came in the query string or in POST data. Well, you might argue that the indifference in the library is also evidence of ignorance at large but that says nothing about the actual developer of any particular application.
GETs should be “safe and idempotent”.
Of course I agree with the basic point and it’s a source of some annoyance to me too. Better yet though are forms that interpret a carriage return in a text (not textarea) field as something other than “form submit”. Argh.
December 26, 2007 at 6:43 pm
Great post, and scary timely for me. I’ve had 2 discussions 2 days apart with 2 very smart people who wanted to make 2 separate search engines use POST and didn’t understand my fervor for GET right away.
My ONLY beef with using a GET is the sending of an x and y paramter ( &x=mouse.x&y=mouse.y) when using input type=”image”. I don’t get why that’s still a hold over from the heady days of “everything’s an imagemap”.
Another benefit to GET searches is google can index them, giving you more pages in their index, and internal links to your own content that will carry juice.
December 18, 2008 at 8:59 pm
There are advantages and disadvantages. GET visibly exposes your data structure and represents a clear invitation to hackers to sleaze on your website. With POST none of that is visible in results – and if its not easy to manipulate it then hackers go elsewhere – they’re lazy as well as indiscriminate.