HTTP Explained: What Really Happens Between Client and Server?

Every time you open a website, refresh a page, submit a form, load an image, or call an API, HTTP is involved somewhere in the process.

You write:

fetch("/api/users");

and somehow a request leaves your device, reaches a server, gets processed, and comes back with a response.

It looks simple from the developer's perspective.

But what actually happens between the client and the server?

Understanding HTTP is one of those things that makes backend development, frontend development, APIs, networking, and system design much easier to understand.

Let's break down what happens when a client communicates with a server.

---

1. What Is HTTP?

HTTP stands for Hypertext Transfer Protocol.

It is a protocol that defines how clients and servers communicate over a network.

The basic model is:

Client
   |
   | HTTP Request
   ↓
Server
   |
   | HTTP Response
   ↓
Client

The client could be:

• a web browser
• a mobile application
• another server
• a command-line tool
• an API client

The server receives the request, processes it, and returns a response.

HTTP defines the structure and rules for this communication.

---

2. The Client Doesn't Just "Call the Server"

Suppose you open:

https://example.com/products

Your browser doesn't magically know where example.com lives.

There are several steps before the HTTP request can actually reach the server.

A simplified flow looks like:

URL
 ↓
DNS
 ↓
IP Address
 ↓
TCP / TLS
 ↓
HTTP Request
 ↓
Server
 ↓
HTTP Response
 ↓
Browser

HTTP is only one part of the entire journey.

This distinction is important.

HTTP defines the application-level communication, while other networking protocols help establish the connection that carries it.

---

3. Step One: The Browser Parses the URL

Consider:

https://example.com/products?id=42

The browser breaks this into pieces:

Protocol: https
Host: example.com
Path: /products
Query: id=42

The URL tells the client where it wants to communicate and what resource it wants.

For example:

https://example.com/products

might mean:

"Give me the products resource."

While:

https://example.com/products?id=42

might mean:

"Give me product 42."

The URL itself doesn't execute the request.

It provides the information needed to construct one.

---

4. DNS Finds the Server

The browser needs an IP address to communicate with the destination.

It asks DNS:

example.com
     ↓
DNS
     ↓
93.184.216.34

DNS stands for Domain Name System.

You can think of it as the internet's naming system.

Humans prefer:

example.com

Networks communicate using IP addresses such as:

93.184.216.34

Once the client has an appropriate IP address, it can continue establishing the network connection.

---

5. HTTPS Adds Security

If the URL uses:

https://

the connection is protected using TLS.

Instead of sending HTTP data as plain text, the communication is encrypted.

Conceptually:

HTTP
  ↓
TLS encryption
  ↓
Network

This protects data from being easily read or modified while traveling across the network.

That's especially important for:

• passwords
• authentication tokens
• payment information
• personal information
• API requests

So when you see HTTPS, think:

HTTP communication protected by TLS.

---

6. The Client Creates an HTTP Request

Now the client can construct the actual HTTP request.

For example:

GET /products/42 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer <token>

An HTTP request generally contains:

Method
Path
Headers
Body (when needed)

For a simple GET request, there may be no request body.

For example:

GET /products/42 HTTP/1.1

is essentially asking:

"Give me resource 42."

---

7. HTTP Methods Tell the Server What You Want

HTTP provides different methods for different operations.

The most common are:

GET
POST
PUT
PATCH
DELETE

A common mental model is:

GET     → Read
POST    → Create
PUT     → Replace
PATCH   → Partially update
DELETE  → Delete

For example:

GET /api/users/42

could retrieve a user.

POST /api/users

could create one.

PATCH /api/users/42

could update part of the user.

DELETE /api/users/42

could delete the user.

The method is part of the contract between the client and server.

---

8. Headers Carry Additional Information

The request isn't just a method and URL.

Headers provide additional metadata.

For example:

Content-Type: application/json
Accept: application/json
Authorization: Bearer <token>
User-Agent: Mozilla/5.0

Headers can communicate things such as:

• what format the client is sending
• what format it expects
• authentication information
• caching preferences
• client information
• cookies
• compression support

For example:

Content-Type: application/json

means:

"The request body is JSON."

While:

Accept: application/json

means:

"I would like JSON in the response."

---

9. The Request Body Contains Data

Some requests need to send data to the server.

For example:

POST /api/users
Content-Type: application/json

with:

{
  "name": "Alex",
  "email": "[e-mail]"
}

The body contains the actual payload.

The server receives it and can validate and process it.

This is common for:

• login
• registration
• creating resources
• updating resources
• submitting forms

---

10. The Request Reaches the Server

Eventually, the request reaches the infrastructure handling the application.

It might look like:

Internet
   ↓
Load Balancer
   ↓
Backend Server
   ↓
Application

The request may pass through multiple layers before reaching your actual application code.

For example:

Client
  ↓
DNS
  ↓
CDN / Load Balancer
  ↓
Web Server
  ↓
Backend Application

This is one reason the phrase "the server" can be misleading.

A production application may actually involve many servers and services.

---

11. The Backend Router Looks at the Request

Suppose the request is:

GET /api/products/42

The backend router might have:

app.get("/api/products/:id", getProduct);

The router matches the request to the appropriate handler.

Conceptually:

HTTP Request
     ↓
   Router
     ↓
GET /api/products/:id
     ↓
getProduct()

The backend now knows which piece of application logic should process the request.

---

12. Middleware Can Process the Request

Before the main handler runs, middleware may perform additional work.

For example:

Request
   ↓
Logging
   ↓
Authentication
   ↓
Rate Limiting
   ↓
Validation
   ↓
Route Handler

Authentication might check:

Authorization: Bearer <token>

Rate limiting might check how many requests the client has recently made.

Validation might check whether the request body has the expected fields.

This allows common responsibilities to be handled consistently across many endpoints.

---

13. The Backend Performs the Actual Work

Now the application logic runs.

Suppose:

GET /api/products/42

The backend might:

Check cache
    ↓
Cache hit?
    ↓
Yes → Return product
    ↓
No
    ↓
Query database
    ↓
Process result
    ↓
Store in cache
    ↓
Return product

The client only sees the API request and response.

All of this work happens behind the API boundary.

---

14. The Server May Query a Database

The backend might execute something similar to:

SELECT *
FROM products
WHERE id = 42;

The database returns the requested data.

The backend can then transform it into the API response.

For example, the database might contain many internal fields:

{
  "id": 42,
  "name": "Keyboard",
  "price": 4999,
  "internalCost": 2100,
  "supplierId": 19
}

But the API might return only:

{
  "id": 42,
  "name": "Keyboard",
  "price": 4999
}

The backend controls what crosses the API boundary.

---

15. The Server Creates an HTTP Response

Once the backend finishes processing the request, it creates a response.

For example:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Keyboard",
  "price": 4999
}

An HTTP response generally contains:

Status Code
Headers
Body

The client receives this response and decides what to do with it.

---

16. Status Codes Tell You What Happened

HTTP status codes communicate the result of the request.

Some common ones are:

200 OK
201 Created
204 No Content

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
429 Too Many Requests

500 Internal Server Error
502 Bad Gateway
503 Service Unavailable

You can think of them as a quick summary of what happened.

For example:

200 → "Everything worked."
201 → "The resource was created."
404 → "I couldn't find it."
401 → "You need to authenticate."
500 → "Something went wrong on the server."

These codes are part of the HTTP contract between client and server.

---

17. HTTP Is Stateless

One of the most important HTTP concepts is that HTTP itself is stateless.

Suppose you make:

Request 1 → Login
Request 2 → Get Profile
Request 3 → Get Orders

HTTP does not inherently remember that Request 2 came from the same user as Request 1.

Each request needs enough information for the server to understand and process it.

Applications build state on top of HTTP using mechanisms such as:

• cookies
• sessions
• tokens
• databases
• caches

For example:

Login
  ↓
Session / Token
  ↓
Future Requests
  ↓
Server identifies user

This distinction is important:

HTTP can carry state-related information, but the HTTP protocol itself is stateless.

---

18. Cookies Help Maintain Sessions

A server can send a cookie:

Set-Cookie: sessionId=abc123

The browser can then include it in future requests:

Cookie: sessionId=abc123

The server can use that identifier to find the associated session.

Conceptually:

Login
  ↓
Server creates session
  ↓
Browser stores cookie
  ↓
Future request
  ↓
Cookie sent back
  ↓
Server identifies session

This is one of the ways applications create a sense of continuity on top of stateless HTTP requests.

---

19. HTTP and APIs

When developers say:

"I'm calling an API."

they are often using HTTP to communicate with that API.

For example:

fetch("https://api.example.com/users/42")

might produce:

GET /users/42 HTTP/1.1

and receive:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Alex"
}

This is why understanding HTTP is so useful.

Once you understand HTTP, APIs stop feeling like magic.

They're structured communication between clients and servers.

---

20. What About POST Requests?

Consider a login request:

POST /api/login
Content-Type: application/json

{
  "email": "[e-mail]",
  "password": "secret"
}

The backend receives it and might:

Receive request
      ↓
Validate input
      ↓
Find user
      ↓
Verify password
      ↓
Create session/token
      ↓
Return response

The response might be:

HTTP/1.1 200 OK

{
  "message": "Login successful"
}

The frontend can then update the application state.

---

21. HTTP Doesn't Mean Every Request Creates a New Physical Connection

This is an important detail.

Developers sometimes imagine:

Request
 ↓
Open connection
 ↓
Send request
 ↓
Close connection

for every single request.

Modern HTTP implementations can reuse connections.

HTTP/1.1 supports persistent connections, and newer protocols such as HTTP/2 and HTTP/3 improve how multiple requests and responses can be transported efficiently.

The key idea is:

HTTP describes the application-level request and response semantics. The underlying connection behavior depends on the HTTP version and transport.

This is one reason modern web performance is more complicated than simply counting requests.

---

22. HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP has evolved.

HTTP/1.1

Requests and responses traditionally use a text-based format and persistent TCP connections can be reused.

HTTP/2

HTTP/2 introduced features such as:

• binary framing
• multiplexing
• header compression
• multiple streams over a connection

This allows multiple requests and responses to be in flight over the same connection more efficiently.

HTTP/3

HTTP/3 uses QUIC, which runs over UDP instead of TCP.

It was designed to improve transport behavior and reduce some of the limitations associated with TCP-based connections.

You don't need to memorize every implementation detail immediately.

The important progression is:

HTTP/1.1
   ↓
HTTP/2
   ↓
HTTP/3

HTTP keeps evolving to make communication more efficient.

---

23. Caching Is Also Part of HTTP

HTTP has built-in caching mechanisms.

A server can send headers such as:

Cache-Control: max-age=3600

This tells caches and clients how long a response can be considered fresh under the specified caching rules.

Caching can happen at different layers:

Browser Cache
      ↓
CDN Cache
      ↓
Reverse Proxy
      ↓
Backend Cache
      ↓
Database

The goal is often simple:

Don't perform the same expensive work if the result can safely be reused.

This can reduce latency and server load significantly.

---

24. What Happens When You Open a Website?

Now let's combine everything.

You enter:

https://example.com

A simplified journey looks like:

Browser
   ↓
Parse URL
   ↓
DNS Lookup
   ↓
Find IP
   ↓
Establish secure connection
   ↓
Send HTTP Request
   ↓
Load Balancer / Server
   ↓
Backend
   ↓
Authentication / Middleware
   ↓
Business Logic
   ↓
Cache / Database / Services
   ↓
HTTP Response
   ↓
Browser
   ↓
Render Page

And remember, this is still simplified.

A real production request may involve CDNs, proxies, multiple backend services, caches, databases, queues, and observability systems.

---

25. HTTP Is a Contract

One of the most useful ways to think about HTTP is as a contract.

The client says:

Here is the resource I want.
Here is the method I'm using.
Here is the information you need.

The server responds:

Here is what happened.
Here is the result.
Here is the data.

For example:

Client
GET /api/products/42
       ↓
       ↓
Server
200 OK
{
   "name": "Keyboard",
   "price": 4999
}

Both sides understand the structure because HTTP defines the rules.

This common protocol is what allows completely different technologies to communicate.

A React frontend can talk to a Node.js backend.

A mobile app can talk to a Java backend.

A Python service can communicate with a Go service.

The implementations can be completely different.

The protocol provides the common language.

---

26. The Bigger System Design Picture

Once you understand HTTP, many system design concepts become easier to connect.

A typical request might look like:

Client
  ↓
DNS
  ↓
CDN / Load Balancer
  ↓
Backend
  ↓
Cache
  ↓
Database
  ↓
External Services
  ↓
Response

Each layer solves a different problem.

DNS helps find the destination.

HTTP defines the request and response.

Load balancing distributes traffic.

Caching avoids repeated work.

Databases provide persistent storage.

Backend services apply business logic.

Queues handle asynchronous work.

Monitoring tells you whether everything is working.

HTTP sits right in the middle of this communication.

---

A Simple Mental Model

When you see:

fetch("/api/users");

don't think:

"I'm calling a function."

Think:

Client
   ↓
Build HTTP Request
   ↓
Find Server
   ↓
Send Request
   ↓
Server Processes It
   ↓
Database / Cache / Services
   ↓
Build HTTP Response
   ↓
Send Response
   ↓
Client Processes It

That's what is really happening.

HTTP is the language that allows the client and server to communicate.

Once you understand the journey of a single HTTP request, concepts like APIs, REST, authentication, cookies, caching, load balancing, proxies, CDNs, and backend architecture become much easier to reason about.

The browser isn't simply "getting a page."

It is participating in a carefully defined conversation between multiple systems.

Request goes in. Work happens. Response comes back.

That's HTTP at its core.