HTTP

• HTTP stands for Hyper Text Transfer Protocol which is an application level protocol for transferring textual data between client and server.

• HTTP is stateless protocol.

• Web Client such as web browser sends the request to server, server responds and sends the requested data (such as a HTML document) or returns error code and closes the connection. Once the response is returned, server doesn't remember anything about the client (even the very next request).

HTTP request methods and Headers

• URL: http://www.server.com:8080/bank/login.html

• Whenever the client sends the request to server for any resource such as a HTML document, it specifies

  1. HTTP method (get/post/put/delete....)

  2. Request URI (eg : /bank/login.html)

  3. Protocol version

  4. Optional Header information (eg : accept, cookies)

• After the client sends the request, server processes the request and sends the response.

HTTP request methods

• The request method indicates to the server what action to perform on the resource identified by the request-URI.

• HTTP 1.1 specifies these request methods, GET, POST , HEAD,OPTIONS, PUT, TRACE, DELETE, CONNECT.

• Servlets can process any of the above requests. But GET and POST methods are most commonly used.

• The GET request method is safe (doesn't change state of the resource) & idempotent (repeated requests do not have any further side effects after the first request).

• The GET request is used typically for getting static information from the server such as HTML document, images, and CSS files. It can be used to retrieve dynamic information also by appending query string at the end of request URI.

The POST request

• The POST request is typically used to access OR create new dynamic resources.

• POST request is used to,

  1. Send the large amount of data to the server.

  2. Upload files to servers

  3. Send serializable Java objects or raw bytes.

GET v/s POST

1. GET request sends the request parameters as query string appended at the end of the request URL, whereas POST request sends the request parameters as part of the HTTP request body.

2. Unlike GET, POST request sends all the data as part of the HTTP request body, so it doesn't appear in browser address bar and cannot be bookmarked.

3. GET is non-secure, whereas POST is secure.

4. GET is idempotent whereas POST is not idempotent.

5. Typically use GET requests to retrieve resource from server.

6. User POST to change some state on server (something like update or create).

7. Some web servers limit the length of the URL. So, if in GET request, too many parameters are appended in query string and URL exceeds this length, some web servers might not accept the request. For POST, we can put request body limit.

Query String

• Query string is used to pass additional request parameters along with the request.

• Query string format

      URL?name1=value1&name2=value&name3=value3...

  • For example,

      http://www.abc.com/test/login.jsp?userid=10&name=abc&age=25

HTTP Response

1. Response status information (eg : 404/200)

2. Response headers (eg : cookies, content-type: text/html, content-length)

3. Response data.

   • Following is an example of HTTP request which uses GET request method to ask for a HTML document named tutorial.html using HTTP protocol version 1.1

       GET /tutorial.html HTTP/1.1

   • Following is the example of request header, which provides additional information about the request.

       User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95)
       Accept: image/gif, image/jpeg, text/*,...

   • Above header specifies the information about the client software and what MIME (Multi-purpose Internet Mail Extension) type the client accepts in response, using User-Agent and Accept headers.

---

Note: Idempotency and safety are properties of HTTP methods.

Safe HTTP methods

• HTTP methods are considered safe if they do not alter the server state. So safe methods can only be used for read-only operations. The HTTP specifications define the following methods to be safe.

  • GET, HEAD, OPTIONS and TRACE.

• In practice, it is often not possible to implement safe methods in a way that they do not alter any server state.

  • For example, a GET request might create log or audit messages, update statistic values or trigger a cache refresh on the server.

• The RFC states,

  • Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

Idempotent HTTP methods

• Idempotency means that multiple identical requests will have the same outcome. So it does not matter if a request is sent once or multiple times. The following HTTP methods are idempotent,

  • GET, HEAD, OPTIONS, TRACE, PUT and DELETE.

• All safe HTTP methods are idempotent but PUT and DELETE are idempotent but not safe.

• Note that idempotency does not mean that the server has to respond in the same way on each request.

  • For example, assume we want to delete a project by an ID using a DELETE request:

      DELETE /projects/123 HTTP/1.1

  • As a response, we might get an HTTP 200 status code indicating that the project has been deleted successfully. If we send this DELETE request again, we might get an HTTP 404 as response because the project has already been deleted. The second request did not alter the server state so the DELETE operation is idempotent even if we get a different response.

• Idempotency is a positive feature of an API because it can make an API more fault-tolerant. Assume there is an issue on the client and requests are send multiple times. As long as idempotent operations are used this will cause no problems on the server side.

HTTP method overview

The following table summarizes which HTTP methods are safe and idempotent:

HTTP Method	Safe	Idempotent
GET	Yes	Yes
HEAD	Yes	Yes
OPTIONS	Yes	Yes
TRACE	Yes	Yes
PUT	No	Yes
DELETE	No	Yes
POST	No	No
PATCH	No	No