.svg)
What are HTTP Requests?
HTTP requests are messages of communication between web API’s and their clients of computers. For those like me who get afraid of complex terminologies this would be like a food court in a shopping complex with our different restaurants as a whole being our web API and each table being our clients who are using our web API to get their job done in this case getting food obviously.
Parts of a HTTP Request
HTTP requests in general have 3 parts which are: -
1. Request line
2. Body
3. The request line specifies what HTTP protocol we are using i.e. which restaurants food we want from the food court.
The Body (which is optional, I guess no food today :( ) has additional information needed for the server i.e., data /content one wants to transmit.
The request's header is where the request's headers are found. To offer information about the request, headers, or metadata, are sent with the request. Each heading is described by its name, followed by two points, and then its value.
Life Cycle of the request
HTTP’s lifetime is simple,
- First, we connect to our server (foodcourt), 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 a 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 a 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 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, as in requestly.io, 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 of such commands include POST, DELETE, UPDATE and so on.
Terminating a HTTP Request
These commands are sent by HTTPS requests if it's okay the server replies with some cookies and a set of headers to execute certain things to achieve your instruction and the connection is broken which is either a: -
- 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.
So our food is served and the connection with the kitchen is no longer needed , happy meal!!
.svg){kind=icon}
