The Expectations of Links
When developing a web page, the user's expectation of what a link does is well understood. Clicking on a link will take you to another page. Within a web application, like Google Mail or Basecamp, links have much more power. They can perform changes, log you out of the application or even delete records.
On one hand, should links even have this kind of power? Links are easily acted upon by search indexers, site copiers, and the performance-enhanching Google Web Accelerator. Each one of these could inadvertently do damage to your application.
John Gruber once said, "the location field is the new command line." But take a look at the actual URL these days and you'll see how true this is. Frameworks like Ruby on Rails are creating easy-to-read and easy-to-follow URL's like "http://www.example.com/email/190/delete".
The HTTP specification recommends against using GET for this type of functionality but it's certainly convenient. A link can be small and unobtrusive. It's scalable. It's a mechanism that people understand. Does the average person understand the difference in functionality between a link and a form submit button? I suspect not, nor do I think it's important that they do. What I do think is important is that a mechanism exists that prevents accidental harm.
The issue is bigger than some automated tool randomly clicking links on you. There's also the harm done by users who've accidentally clicked on links or buttons that they shouldn't have. And in this situation, it doesn't matter whether it's a link or a form button submitting the information via POST. What matters is that a user has initiated an action that they didn't want. In Hotmail, for example, when viewing a message, the Forward button is right next to the Delete button. If I were too quick or my mouse button stuck for half a second then I might hit that Delete button. With no confirmation, my email would disappear in a flash. (In this particular case, Hotmail has a Trash Can from which I can recover that email.)
Allow me to provide another example that has happened to me on more than one occassion. I often like to use the keyboard or scroll button on the mouse for navigation but the document has to be selected before I can do that. I have to click within the page to give it focus. Every now and then, though, I'll end up clicking some random link or advertisement (yep, you've gotten a few clickthroughs from me!). This particular example is pretty harmless until that one day I accidentally click on the wrong link!
This is also an issue that affects some of those who are physically impaired. Hitting a spot on the screen can be more difficult and that person has a higher rish of accidentally hitting the wrong link.
The solution to this is offer a confirmation allowing users to prevent such a thing from happening. Just like every application asks you to save that document before closing it, ask your users if they really want to perform dangerous operations. There are two ways to do this: client-side and server-side. On the client-side, use JavaScript to prompt the user before following the link or submitting a form. On the server-side (for those who do not have JavaScript enabled), display a confirmation page after the user clicks on the link.
For some further discussion more specifically related to the Google Web Accelerator, check out Ian Bicking and Signal vs Noise.
Conversation
Just a note about Rails - there's ways of easily creating links to deleting objects which ask for confirmation.
<%= link_to "Delete this invoice", { :controller => "invoices", :action => "delete", :id => @invoice.id }, :confirm => "Are you sure you want to delete this?" %>(taken from What is Ruby on Rails?)
Of course, that's only client side. Visit the link directly (object/delete/id) and it's gone.
If you are using links, e.g. for a delete action (because it's easier to style...), providing a confirmation page has the additional advantage that you can then use a action="POST" form to perform the 'state of the universe' changing action.
Although spiders and bots are usually not a problem (because any sane web app requires a login for such an action), things will get difficult, if browsers start prefetching - or the other way round: browsers cannot implement proper prefetching, because they have to fear unintended side effects...
I'm glad you wrote about this, Jon.
It's interesting from a design perspective as well, because as you mention, the expectation is that you will go to a new page when you click a link.
But to be fair, that expectation was destroyed a long time ago. Most of the time, you don't know what a link is going to do -- go to a new page, perform an action immediately, reveal something on the page, open a popup, show a javascript confirmation, etc.
I think there's a big opportunity for web designers to add affordances to links, so that it's clear -- before clicking -- what will happen.