HTTP is your wrench
<a href="posts/http-is-your-wrench/delete">Delete article</a>
I think you can answer in 5 seconds. GET requests, like the ones generated by hyperlinks, should be idempotent (mathematical word that means executing them from 1 to N times does not change the end result.) It should not modify any resource present on the server.
The POST method (and other methods not commonly supported by browsers without an overloaded POST) can be used for modifications of resources. Thus usually delete buttons are more popular than delete links, and they send a POST request generated by their <form> element.
Why following this approach? Because, it is in the semantics of the HTTP standard: a Delete article link can theoretically be followed by a crawler or other automated mechanism (after all, it's idempotent, thought the crawler while deleting everything in the database.) Or its result can be incorrectly cached, although it makes no sense to delete a blog post or an user more than once.
What's wrong here instead?
<documentrequest> <language>en</language> <query>original http specification</query> </documentrequest>
In this XML request, we're using a superstructure for our metadata (the language we want the response to be written in), while HTTP already provides standard headers, such as Accept-Language for defining this information.
This SOAP-like request is one simple example of reinventing a square wheel instead of harnessing the one already defined for us by a twenty-year old standard adopted by any computer on the planet (try finding an operating system distributed without a browser).
These are only two examples. HTTP is not only a very popular standard, but also an example of distributed system that works really well. If you compare it to Java Rmi, whose false transparency and timeouts can cause front-end outages, it is extremely robust. The same goes for the comparison with other Remote Procedure Call mechanisms.
If you want to build a distributed system in 2011, you have under your eyes an example of a magnificent case study: a large, interoperable system called World Wide Web, where machines with different operating systems communicate flawlessly, without the need for custom clients.
If you're here I guess you are a web developer like me. If you serve HTML pages for a living (or write code that does it for you, hopefully), you have no excuses in not knowing the basics of the HTTP protocol, from which any part of your work that the user can see will pass.
What to read
The HTTP 1.1 specification (RFC 2616) is probably the key document to read once in your life. It is really complete, as it by definition is the standard. However, it is very abstract, in order to provide timelessness I guess. It was written in 1999 to update a 1990 standard.
It's also boring in many sections, since it describes not only the concepts of HTTP but also the physical formats of requests and responses and low-level specifications that you may never use unless you write an HTTP client.
So where can we find some more up-to-date material about HTTP usage? And maybe comparisons with other styles like RPC and SOAP which did not exist when the HTTP specification was written?
The answer resides in the REST material. REST (Representational State Transfer) is the architectural style which proposes the web decentralized model to be used for the communication of machines and not only humans. Today's public web services are written almost only in a REST-like style.
It may be the case that you would never have to write a web service, but some REST knowledge will definitely help you in designing the URLs of your application, the methods for accessing them, which headers to send and so on.
Architectural Styles and the Design of Network-based Software Architectures, commonly known as Roy Fielding's Ph.d. thesis provides an official presentation of REST, especially in its chapter 5. Roy Fielding is one of the authors of the HTTP specification, so it's actually the same source.
RESTful Web Services is instead a complete book, published in 2007, which teaches you how to conform to REST in web service clients and servers. It has several insightful examples of how REST is not only a shift in using HTTP at its best, but also in presenting resources (identified by Urls) more than methods to call, which would be typical of RPC. For example, a resetting a password in REST can be viewed not as an action to call, but more a /user/42/password-reset to create with a PUT or with a POST on /user/42.