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

submit button.
Listing 7.1. Link Converted to a Form
<form method="post" action="/admin.php">
<input type="hidden" name="action" value="approve" />
<input type="hidden" name="id" value="1798" />
<input type="submit" value="Approve" id="approve" />
</form>
Browsers will show a single button for this action. Some more modern browsers, including Firefox, let you style
the button so that it looks more like a link with a CSS rule such as this one:
input#approve {
border: none;
background: white;
color: blue;
text-decoration: underline;
}
However, other browsers, including Safari, always show a button no matter what styles you apply. I think using
a button instead of a link is no big deal. It's probably friendlier to users who associate buttons with taking an
action and following links with simple surfing. However, if you really, really hate buttons, there's something else
you can do. You can retain the original link but have it point to a page containing a confirmation form. No action
is actually taken until the confirmation form is submitted, so the link can still use GET. The confirmation form
uses POST. This seems a little involved to me, but it does allow you to keep buttons off the main page and
retain the overall look, feel, and layout of that page while still using the proper HTTP verbs.
On the server side, a little more work is usually required to switch from GET to POST, but not an excessive
amount. The details of how you switch from GET to POST on the server side will vary depending on the
environment in which your server-side programs are written. In most cases, though, it's straightforward. For
instance, if you're using Java servlets, you can handle many cases merely by renaming the doPost() method to
doGet() . The arguments and the logic are the same. If you're using PHP, you may well be able to just change
$_GET['name'] to $_POST['name'] .
The ease with which such frameworks enable one to switch between methods, combined with some bad early
tutorials that were widely disseminated, has created a common antipattern in which scripts are written that
accept requests via both GET and POST, and do the same thing in each case. This is dangerous and almost
always a mistake. Most server-side programs should accept arguments via one or the other, not both.
It is possible to design a system in which a script takes different actions when you access it via GET or POST.
For example, http://www.example.com/cars/comments might return a page with all the comments when you
access it with GET and add a new comment to the page when you access it with POST. However, this pattern is
uncommon in practice. Usually separate pages are set up to receive GET and POST requests.