HTTP is a synchronous request-response application network protocol. Client sends a request specifying one of the seven HTTP methods, the location of the resource to be invoked, a set of optional headers and an optional message body. The server sends back a response containing the version of HTTP we are using, a response code, a description of the response code, a set of optional headers, and an optional message body. HTTP is the primary protocol for most web applications on the Internet, regardless of whether they are written in Java, PHP or ASP. 

HTTP Versions

Important versions that need to be considered are HTTP/1.0 and HTTP/1.1.

HTTP/1.0 defines the basics protocol with some methods such as GET, POST and HEAD, and did not support informational status codes.

HTTP/1.1 defines seven HTTP methods GET, POST, HEAD, OPTIONS, TRACE, PUT, DELETE, and also add many headers and facilities to the original HTTP/1.0.

The seven HTTP methods

The seven HTTP methods are GET, POST, HEAD, OPTIONS, TRACE, PUT, DELETE:

1. GET - It’s meant to be a “read-only” request for information from a server. With a GET request, parameters are appended to the URL. The three standard triggers for a GET request are:

   1. Typing into the address line of the browser and pressing go

   2. Clicking on a link in a web page

   3. Pressing the submit button in an HTML <form> whose method is set to GET.

2. POST - Triggered from forms in browsers, when the form method is set to POST. Whereas GET is intended as read-only, POST is for add/update/delete operations. When there are parameters with a POST request, they are put into the request body, not appended on to the query string of the URL, as for GET.

3. HEAD - identical to the GET method, but doesn’t return a message body. However, all the response headers should be present just as if a GET had been executed. Using the HEAD method is an economical way of checking that a resource is valid and accessible, or that it hasn’t been recently updated.

4. OPTIONS - Tell the requester what HTTP methods can be executed against the URL requested.

5. TRACE - The purpose of TRACE is to return the request back to the requester in the state it was in at the point where it reached the last computer in the chain. The primary reason for doing so is to debug some problem that you attribute to request header change.

6. PUT - Take a client resource and put it in a location on a server as specified in the URL of the request. If there’s anything already on the server in that location a PUT will overwrite the current contents of the URL with the file it is uploading. You can determine from the response codes you get back whether the resource was replaced (typically, response code 200) or created for the first time (response code 201).

7. DELETE - It causes the server to delete the contents of the target URL. A server has the right to delay its response to a DELETE method, as long as it responds later. A response code of 200 (OK) indicates that the delete has been done; 202 (accepted) means that the request has been accepted and will be acted on later.

Beyond the seven main HTTP methods, there is CONNECT which is officially listed in the RFC, but it is essentially reserved for future use.

GET vs. POST

GET and POST are the most commonly used HTTP methods. With a GET request, parameters are appended to the URL as query string. A question mark introduces the query string as in http://www.javajee.com?q=user. When there are parameters with a POST request, they are put into the request body, not appended on to the query string of the URL, as for GET. Major advantages of sending parameters within the request body for a POST are:

• A URL is limited in length and hence there will be a limitation in the amount of content you can put in an url during a Get operation. However the request body can be any big we want and hence there is no size limitation like GET for POST.

• Putting parameters into the URL is very visible and public and is usually recorded by the “history”-keeping nature of most browsers. Hence sending parameters within the request body for POST is more secure.

Idempotency and safe/unsafe operations

The HTTP methods can be classified based on idempotency and safe/unsafe operations: 

Idempotent request

An idempotent request is meant to have the same result (and no irreversible side effects) no matter how many times it is executed. Of the seven methods, POST is the only one that is not considered “idempotent.” 

However the behavior cannot be guaranteed. For example, GET is supposed to be idempotent, whereas POST is not. However, there is no absolute guarantee that any given GET request won’t have irreversible side effects. The outcome depends on what the server program that receives the GET request actually does with it. Equally, a POST request may not result in an update. However GET and POST methods in general obey idempotency rules and your web applications should observe them.

Safe and non-safe

GET, TRACE, OPTIONS, and HEAD should leave nothing changed, and so are safe. Even if a GET request can have irreversible side effects, a user should not be held responsible for them. Therefore, from a user perspective, the methods are safe.

PUT, DELETE, and POST are inherently not safe: They do cause changes, and a user can be held accountable for executing these methods against the server. PUT and DELETE are disallowed on most web servers.

HTTP Status Codes

HTTP shares the status of a request with the requester through the use of status codes, which are sent back along with the response. There are five classes of status codes: 

• Informational (1XX)

• Successful (2XX)

• Redirection (3XX)

• Client Error (4XX) 

• Server Error (5XX).

Example 

• 100 ('Continue') is reported during a connection with the client and indicate that the server is continueing to process the request.

• 200 ('OK') indicate that a complete response has been correctly prepared.

HTTP and Java

Servlets are java components that can respond to an HTTP request.

There are methods in Java Servlets corresponding to each of the HTTP methods. 

The seven HTTP methods map on to seven servlet methods of the same name with a “do” in front (e.g., POST maps on to doPost()).

The doXXX() methods receive two objects as parameters—the first representing the HTTP request and the second the HTTP response.