The Request-Response Cycle

The web is a conversation. You speak, it answers.

Every click, every scroll, every form submission—these are questions. The server's job is to respond. This back-and-forth, repeated billions of times per second across the planet, is the request-response cycle. It's how HTTP works, and understanding it means understanding the web itself.

You Speak, It Answers

HTTP follows a simple rule: clients ask, servers answer. The client always goes first. A 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 Has Amnesia

Here's something strange: 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 ever happened. Your next request? Fresh start. No memory of what came before.

This seems limiting, but it's actually what makes the web scale. When servers don't need to track ongoing conversations with millions of clients, they can handle far more requests. State—when you need it—gets maintained through cookies, tokens, and session identifiers that the client sends with each request. The server reads these attachments and reconstructs context on the fly.

The amnesia is a feature, not a bug.

What's in a Request

Every HTTP request contains four pieces:

The Method tells the server what you want to do:

• GET: Fetch 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? Usually POST.

The URL specifies exactly what you want:

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

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

Headers provide context—key-value pairs that tell the server about you and what you can handle:

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

The Body carries data for POST, PUT, and PATCH requests—form submissions, JSON payloads, 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 is a three-digit number summarizing the outcome:

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

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

Headers provide metadata about the response:

• Content-Type: The format of the response body
• Content-Length: How many bytes are coming
• Set-Cookie: Instructions to store cookies
• Cache-Control: How long you can cache this
• 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 handed over the data. Conversation complete.

Keeping the Line Open

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

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 by staying on the line.

Where Time Goes

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

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

A cached local resource might return 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 fast.