Web Applications - Refactoring HTML: Improving the Design of Existing Web Applications - page 245

Reading e-mail
Viewing a map
Inspecting the current state of a machine
Again, this is just a sample. There are many more.
A few operations straddle the line. For example:
Adding an item to a shopping cart (but not immediately purchasing it)
Previewing a comment on a blog
I'd probably use POST for adding an item to a shopping cart simply because I don't want a browser to do this
automatically. This may not commit the user to buy the item, but it still changes the state of the shopping cart.
If an item were added automatically, the user would then have to remove the item from the cart.
Whether I implemented previewing as GET or POST might depend on implementation details and convenience.
It would not be a problem for a browser to prefetch a preview or for someone to link to it. However, if the
preview in some sense actually creates the comment resource but just doesn't allow it to be shown to the other
users yet, POST is more appropriate.
Using GET where POST is called for can have potentially disastrous consequences. In the worst case I know of,
Google deleted an entire government web site that had used GET for all operations.
Do not rely on cookies, nonces, hidden form fields, nonhidden form fields, JavaScript, HTTP authentication,
referrer checking, or other tricks to hide the GET links from spiders. The Google web accelerator caused massive
problems for many diverse web sites that weren't expecting users' browsers to begin following every link on the
page. In this case, users were already logged in and had all necessary credentials to perform dangerous
operations.
These are only the most famous examples. There have been many others over the years. The bottom line is
this: HTTP is designed to clearly separate what you do with POST from what you do with GET. When you design
web applications to use POST for what POST was designed for and GET for what GET was designed for,
everything works and works well. When you mix them up and try to tunnel GET through POST or POST through
GET, trouble ensues. You can spackle over the problems and spend your life putting out fires as one problem
after another crops up, or you can use HTTP the way it was meant to be used.
If you do uncover any forms or links that are using GET where they should be using POST, fix them. The only
client-side change that's usually needed is changing method="get" to method="post" on the form element.
If the unsafe operation is being triggered by a link, replace it with a form. You can use hidden fields to fill in the
values of the query string variables. For example, suppose you have this link:
<a href="/admin.php?action=approve&amp;id=1798">Approve</a>
It has two fields: action with the value approve , and id with the value 1798 . Each field in the query string
becomes a hidden field in an equivalent form shown in Listing 7.1 . The text of the link becomes the text on the