HTTP!

HTTP is the protocol which enables your web applications to interact with resources located anywhere on the internet. On the most basic level, the protocol takes the form of request/response. Here, a client program establishes a connection with a server and begins making requests. Likewise the server, once a connection has been established makes a series of responses.

Upon closer inspection, we see that this response/request interaction is defined by one of seven core request methods available to the client. These methods are as follows:

• GET
• POST
• PUT
• DELETE
• HEAD
• OPTIONS
• TRACE

Each of these tokes defines the action the client wants the server to make on the resource specified in the URI (Universal Resource Identifier, which is the combination of URLs (Locators) and URNs (Names)--ok, they're also known as WWW addresses).

Think of the request protocol like a grumpy caveman: He points at a given resource (via URI) and makes his demand: "GET!" then "PUT!" then "DELETE!" You get the picture.

The first four methods in the list might be seen as "active use" methods, since they define active interaction with a given resource. The last three options are mostly reserved for "test use" and are used mostly to test the attributes of a given server or communication state. We're not going to worry about the test use methods for now.

The Four Active Methods (Careful, I made up the phrase "active method")

GET is the most common of the HTTP methods, and it pretty much works as advertised: it requests that the server fetch and send over a given entity (head+body) specified in the URI. Every server is required to respond to GET. GET is designed to be a "safe" operation since it does not change the resource and it does not perform any legally binding operations (such as seal an agreement)--it merely supposes retrieval of information.

POST asks that an enclosed entity be worked into the structure of the identified resource. This action enables network-based annotations, online posts, form submissions and mediated database updates. As you may imagine, it is considered an "unsafe" operation and servers are not required to support POST requests.

PUT asks that a given resource be stored under the requested URI. This could be an altogether new resource or it could replace the existing resource. Whereas the POST method uses a URI to specify a handling resource which contains the processing logic to work the new resource into the existing body, the PUT uses the URI to refer to the resource it is supplying. (unsafe/not required)

DELETE asks that a server delete the resource identified in a URI. (unsafe/not required)


Resources:

Hypertext Transfer Protocol -- HTTP/1.1 RFC 2068
WC3 Article on Methods, URIs and Safe/Unsafe Interactions