Understanding HTTP for Backend Engineers

Every time we open an app or make an API call, we are dealing with the HTTP protocol, which powers the internet invisibly.

Knowing and learning about this protocol is the most fundamental part for any backend engineer. And it has a lot of layers to it. So I’ll be covering it in multiple parts. Please follow along as we explore piece by piece.

The Client–Server Model

Let’s start by understanding what a client is and what a server is.

Server - A server is like a computer thats sitting somewhere remotely and which provies or serves the resources or the data on requesting.
Eg: web server, data server.
Client - A client is like a device that requests services or data from the server accepts the data. Eg: Web browser (Chrome), Mobile App etc

In a client server model, its the client that initiates the communication by sending a request, and the server sending the requested information.

So the question might arise as to how the client actually sends the request to the server and how the server responds with the data to the client. This is where HTTP (Hyper Text Transfer Protocol) comes in.

HTTP Protocol

So this is a protocol which defines how clients and servers talk to each other. HTTP protocol defines a set of rules as to how messages are sent and recieved over the web between clients and servers.

A HTTP request has 3 main parts:

Request line - Defines the HTTP method, resource route path, and HTTP Version
Headers - Provides metadata or additional info aboutthe request.
Body - Data sent to the server from the client.

A HTTP response also has a structure:
Status Line- HTTP version + Status Code and Status Value
Headers- These are response headers which contains meta data about the response.
Body- The actual data being sent back from the server.

Now you might be wondering, What exactly are these HTTP versions and which one are we using today?

HTTP Versions

HTTP/1.0: This is the basic request response, Every request to the same server requires a separate TCP connection.
HTTP/1.1: A TCP connection can be left open for reuse (persistent connection), but it doesn’t solve the HOL (head-of-line) blocking issue. HOL blocking when the number of allowed parallel requests in the browser is used up, subsequent requests need to wait for the former ones to complete. Uses the concept of Pipelining for maintaining the same TCP connection for requests.
HTTP/2.0: This addressed the HOL issue that was there in HTTP/1.1 using request multiplexing. Request Multiplexing allows multiple requests and responses to be sent concurrently over a single connection, eliminating head-of-line blocking and significantly improving performance
These involve lot of networking concepts which in itself is not very important but good to know for every backend engineer.

HTTP Request Response Cycle

Now that we understand clients, servers, and the protocol itself, let’s look at how a complete HTTP transaction happens.

When a client sends a request, it travels through multiple layers (DNS lookup, TCP connection, etc.) until it reaches the server. The server then processes that request, performs the necessary logic (like querying a database or validating credentials), and finally sends back a response.

The sequence looks like this:

Client opens a connection to the server (using TCP).
Client sends an HTTP request (method + headers + optional body).
Server receives and processes the request.
Server sends back an HTTP response (status code + headers + optional body).
Connection may stay open (persistent) or close after completion.

In the next post, we will look at different HTTP Methods, different HTTP Status Codes, the Request and Response Headers, and understand how they all work together.

Thanks for reading, and if you liked it, please leave a clap, share it with your fellow backend engineers, and follow me for the next part.

Image Credits

Understanding HTTP for Backend Engineers - Part 1

Subscribe to my Substack