The Request-Response Cycle

Every click is a question. Every page load is an answer.

This exchange—client asks, server responds—happens billions of times per second across the planet. It's called the request-response cycle, and it's how HTTP works. Understanding it means understanding the web itself.

The Client Always Speaks First

HTTP follows a strict rule: clients ask, servers answer. The server cannot spontaneously send you data—it can only respond to requests you've made.

This creates a predictable rhythm. Your browser asks for a page. The server sends the HTML. Your browser asks for the images. The server sends them. Each exchange is complete in itself. The conversation moves forward one question at a time.

The Server Forgets You Instantly

Here's the strange part: the server doesn't remember you.

HTTP is stateless by design. Each request arrives as if from a stranger. The server processes it, responds, and immediately forgets the interaction happened. Your next request? Fresh start. No memory of what came before.

This seems like a limitation. It's actually the reason the web scales.

When servers don't maintain ongoing relationships with millions of clients, they can handle far more requests. Any server in a cluster can handle any request. Crash and restart? No sessions lost, because there were no sessions to lose.

So how does anything remember you? Cookies, tokens, and session identifiers—data the client sends with each request. The server reads these attachments and reconstructs context on the fly. Every request arrives carrying its own history, like a stranger holding your photo and claiming to know you.

We built the web's memory on a protocol designed to forget.

What's in a Request

Every HTTP request contains four pieces:

The Method declares intent:

• GET: Retrieve something without changing it
• POST: Submit data to create something new
• PUT: Replace something entirely
• PATCH: Update part of something
• DELETE: Remove something

Loading a page? GET. Submitting a form? POST.

The URL specifies the target:

https://api.example.com/users/123?include=profile

The path (/users/123) identifies the resource. The query string (?include=profile) passes parameters.

Headers provide context—key-value pairs describing you and what you can handle:

• Host: Which domain you're addressing
• User-Agent: What software is making the request
• Accept: What response formats you understand
• Authorization: Your credentials
• Content-Type: The format of data you're sending
• Cookie: Session data and identifiers

The Body carries payload for POST, PUT, and PATCH requests—form submissions, JSON data, file uploads. The Content-Type header tells the server how to interpret it.

What's in a Response

The server's answer has three parts:

The Status Code summarizes the outcome in three digits:

• 2xx: Success. You got what you asked for.
• 3xx: Redirect. What you want is somewhere else.
• 4xx: Client error. You asked wrong.
• 5xx: Server error. The server broke.

You'll see 200 (OK) constantly. 404 (Not Found) when resources don't exist. 500 (Internal Server Error) when something fails on the server's end. 301 (Moved Permanently) when content has relocated.

Headers provide metadata about the response:

• Content-Type: The format of the body
• Content-Length: How many bytes are coming
• Set-Cookie: Instructions to store data for future requests
• Cache-Control: How long you can reuse this response
• Location: Where to go (for redirects)

The Body contains the actual content—HTML, JSON, images, whatever you requested.

A Complete Exchange

Your browser fetching user data from an API:

Request:

GET /api/users/123 HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Response:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 145
Cache-Control: max-age=300

{
  "id": 123,
  "name": "Jane Smith",
  "email": "jane@example.com",
  "created_at": "2024-01-15T10:30:00Z"
}

You asked for user 123 with proper credentials. The server confirmed success (200), told you it's JSON, and sent the data. Conversation complete.

Staying on the Line

Early HTTP opened a new TCP connection for every request—like hanging up and redialing between each sentence of a phone call.

Modern HTTP keeps connections alive. One TCP connection handles multiple requests, eliminating the overhead of constant reconnection. HTTP/2 goes further: multiple requests and responses flow simultaneously over a single connection, interleaved rather than queued.

The conversation got faster when we stopped hanging up.

Where Time Goes

A request-response cycle isn't instant. Time accumulates:

1. DNS Lookup: Translating the hostname to an IP address
2. TCP Handshake: Establishing the connection
3. TLS Negotiation: Setting up encryption (for HTTPS)
4. Server Processing: Generating the response
5. Content Transfer: Sending the bytes

A cached local resource returns in milliseconds. A complex API call to a distant server might take seconds. Each stage offers optimization opportunities—prefetch DNS, reuse connections, cache responses, compress content.

Understanding where time goes is how you make the web feel instant.