Life Cycle of a HTTP Request

In the vast realm of web development, it is crucial to understand the life cycle of an HTTP request. In this blog, we explore the intricacies and stages that shape the HTTP request lifecycle, deep-diving into the behind-the-scenes processes that power our online experiences using a simple analogy.

What are HTTP Requests?

HTTP requests serve as the foundation of communication between web APIs and their clients, enabling the exchange of data and resources. For those like me who get afraid of complex terminologies, to understand this concept better, let’s draw an analogy to a bustling food court in a mall.

Imagine the food court as the web API, offering a diverse range of culinary delights from various restaurants. Each restaurant represents a different endpoint or functionality provided by the API, catering to the specific needs of the clients.

Now, picture the clients as individuals or groups of people sitting at tables within the food court. These clients rely on the web API to accomplish their tasks, much like customers relying on restaurants to satisfy their hunger.

Similar to how clients in the food court interact with the restaurants, clients in the web API ecosystem interact with different endpoints to retrieve, modify, or submit data. Just as customers at the food court place orders and make requests to the restaurants, clients make HTTP requests to the API endpoints, specifying their desired actions and the necessary parameters.

Parts of a HTTP Request

HTTP requests, in general, have 3 parts which are: –

1. Request Line: The request line specifies the HTTP protocol being used and communicates the specific resource or action the client is requesting from the server. It’s akin to ordering food from a restaurant, indicating which cuisine or dish you desire from the food court.
2. Body (Optional): The request body, although optional, provides additional information that the server may require. Think of it as the contents or data you want to transmit alongside your food order. Unfortunately, in this case, it seems we won’t be getting any food today.
3. Request Headers: The request headers are where vital information about the request is conveyed. These headers, or metadata, accompany the request to provide context and details. Each header is defined by its name and serves a specific purpose in the communication process.

Life Cycle of the request

HTTP’s lifetime is simple,

• First, we connect to our server (foodcourt) by entering an URL, and our browser gives a request to connect to a socket (just like calling for a waiter). After that, the request reaches the socket(waiter) and is accepted, i.e., port 80 if we use HTTP.
• The process of establishing a connection between a client and a server is done by a process called a 3-way handshake. Firstly, our first handshake is executed by our client sending an SYN (synchronization) segment request to our server so as to tell the server that it wants to connect to the server. Now if we have a valid request, our server also sends an SYN+ACK(acknowledgment) request back to our client (The ACK part is for telling that it accepts the SYN request by our client to create a connection over which the client can send data, The SYN part is because the server also wants to create a connection over which it can send data to the client so essentially trying to create a DUPLEX connection).In response to the servers SYN request now, in turn, our client sends an ACK request, and voila, our connection is established.

• Now, our local system will make a call to the domain name service, which converts the domain name to an IP address.

DNS Resolution‍

For those of you who don’t know about how domains work – websites are generally deployed on a server, and the webpages are served to the users on an IP address, say 148.168.14.2. It is obviously difficult to remember the IP for each website, so we have domain names, such as requestly.io and google.com. These domains correspond to a specific IP address. So, when a user hits requestly.io on the browser, the local device finds out the IP address corresponding to it and fetches the pages from that IP address.

• Let’s get back to the HTTP lifecycle. Once it knows our IP address it will try to connect to our port, and if everything is good, we will be connected. This entire process is similar to someone ordering food and getting a reply from the kitchen if the dish is available or not.
• Next begins our cooking part, where our HTTP protocol starts executing; whatever commands you may require on its API server are being executed, and data is now being exchanged from the established link; for example, you type PUT or say GET. The HTTP PUT request method creates a new resource or replaces a representation of the target resource with the request payload. Similarly, GET is used for getting or fetching data from the server, such as the page index or user details. Most such commands include POST, DELETE, UPDATE, and so on.

Terminating a HTTP Request

These commands are sent by HTTPS requests, and the server replies with some cookies and a set of headers to execute certain things to achieve your instruction. Once the command is executed the connection will be broken, which can be either one of the two ways mentioned below:

• Graceful close – Clients will wait for the peer on the other side of the connection to close its output channels before gracefully closing their own output channels. The connection can be completely terminated without the possibility of a reset if both parties have finished notifying one another that they won’t be sending any more data (i.e., closing output channels).

• Full and half close – Here, one or both of the TCP input and output channels can be closed by an application. A TCP connection’s input and output channels are both closed by the close() socket operation. This is referred to as a “full close.” To shut down the input or output channel separately, use the shutdown() sockets call. The figure illustrates what is known as a “half close” in this situation.

In conclusion, the life cycle of an HTTP request is a fascinating journey that underpins seamless web communication. From the initial request line that specifies the desired resource to the optional request body and the essential request headers, each component plays a crucial role in transmitting information between clients and servers.

Understanding the life cycle of an HTTP request empowers us to optimize web performance, troubleshoot issues, and build efficient applications. By grasping the underlying processes, we gain the ability to craft seamless user experiences and ensure reliable communication between clients and servers.

So our food is served and the connection with the kitchen is no longer needed , happy meal!!

‍