Sun Certified Web Component Developer/Section1/HTTP Methods

HTTP is a simple, yet powerful protocol, created at the beginning of 1990s to transport text (first ASCII, then HTML). Its functioning is very simple explaining why it spread so fast. The idea behind it is that there is a resource in the server and the client wants to action over it. For each possible action there is a method in the protocol. The methods available for the protocol are the ones for the basic CRUD operations, plus some other client-server and proxy-server communications methods.

HTTP Methods and JEE

In the JEE specification, the Web container handles the protocol details and when using HTTP as the communication protocol (the very most part of the situations) the container redirects the request to a class that extends HTTPServlet. The HTTPServlet class is a do nothing handler for HTTP methods. For each one of the protocol methods, except Connect, there is an equivalent method inside the HTTPServlet class. For example, for the Get method, there is the doGet method inside the class.

All of them receive to arguments: HTTPServletRequest and HTTPServletResponse. Through these two interfaces it is possible to get access to the input stream that was created with the client and where the request came from and is also possible to get access to the output stream where the answer to the client is going to be written. Actually, that is the way that, normally, servlets answers HTML to clients, though is not the most recommended way to do it.

HTTPServletRequest also gives access to many other features such as session management, request parameters and many other features described at HTTP Request.

HTTP Response also has many other features mainly related to dispatching the response to the correct place.

HTTP Methods and the Exam

For the SCWCD exam, it is not necessary to understand deeply each one of the methods, only two of them are explored because they are, by far, the most used on day-to-day job: GET and POST. The full list of methods and descriptions for each one of them can be found at the Wikipedia page for the HTTP protocol, it is recommended that you read this page and understand the basics of the protocol before continue.

POST and GET

These two methods are the most simple to use and most of the time, what the client need is just to get something from the server. Some times things get more complicated and the user needs to change something in the server, and that is why Post is there for us. The protocol was build with that in mind, the user would get things from the server and post things there.

The main difference between these two methods is that POST have a body while GET does not. This body can be used to send data from the client to the server to change something. Any amount of data can be sent in this body.

GET can also send data to the server, but in a different way. A URL can have a query part. This query is where get can send data to the server. The question mark (?) is used to separate a resource from the query part of the URL. POST can do that too, data can be sent in both, the body and the URL in a POST request.

There are two drawbacks in sending data in the URL:

1. the first one is that there is a limit of data that can be sent, and in most browsers that is 256 characters - it is a lot but if there is a large form to send, data can be left out
2. the second one is confidentiality, because when you send data in he URL it is exposed to any one that can see the browser or the URLs being requested and the user might want to bookmark it and the data will be saved together with it, that is not good if a credit card number or any other confidential data is being sent

Another difference between these methods is that, as the protocol was designed to, POST - in theory - is NOT idempotent. That means that if you execute the same request twice, the results might come out different. Notice that a in theory was added in the middle of the last phrase because an application can be designed to make a GET method change something in the server and so, result in a different answer for each request. The protocol was designed to be so that GET IS idempotent and POST IS NOT, but the way they are implemented is the developer's choice.

Another important thing to notice is that users don't like to wait, so they will (surely) click more than once in a button after the first request was sent. One thing the application should guarantee is that things like paying for something twice in a web application does not happen. Normally, following the basic rule described in the last paragraph helps. Synchronizing important requests - like paying for a product - can be one way out of this tricky problem.