A little HTTP explainer

http-explainer-brett-victor-style.md

HTTP, Seen as a Conversation

A small explainer in the spirit of Bret Victor: make the invisible visible.

HTTP is not a cloud. HTTP is not magic. HTTP is one machine sending a little text message to another machine, and getting a little text message back.

┌─────────┐                         ┌─────────┐
│ Browser │                         │ Server  │
└────┬────┘                         └────┬────┘
     │                                   │
     │  "Please give me /todos"          │
     │ ───────────────────────────────▶  │
     │                                   │
     │  "Sure. Here are the todos."      │
     │ ◀───────────────────────────────  │
     │                                   │

That is the whole shape of HTTP:

request  ─────▶
response ◀─────

---

A request is a wish with a label

When the browser wants a page, it sends a request.

GET /todos HTTP/1.1
Host: example.com
Accept: text/html

Read it like a sentence:

GET        /todos      from example.com
│          │           │
│          │           └─ the machine I am talking to
│          └───────────── the thing I want
└──────────────────────── what I want to do

The method is the verb.

GET     read this
POST    create this
PUT     replace this
PATCH   change this a little
DELETE  remove this

---

A response is an answer with a mood

The server replies:

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Todos</h1>

The first number is the mood of the answer.

200  OK                 "Here it is."
201  Created            "I made it."
204  No Content         "Done, nothing to show."
400  Bad Request        "I don't understand."
401  Unauthorized       "Who are you?"
403  Forbidden          "I know you, but no."
404  Not Found          "That isn't here."
500  Server Error       "I broke."

Status codes are not data. They are the server pointing at the outcome.

request:  GET /cat-picture
response: 404 Not Found

The server did not send a cat.
It sent a fact about your request.

---

Headers are sticky notes

Headers are little notes attached to the message.

Content-Type: application/json
Authorization: Bearer abc123
Cache-Control: max-age=60

They do not usually contain the main thing. They describe the main thing.

Content-Type     "The body is JSON."
Accept           "Please send JSON if you can."
Authorization    "Here is my badge."
Cache-Control    "You may reuse this for 60 seconds."

---

The body is the thing being carried

A message may carry a body.

When you create a todo:

POST /todos HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "text": "Buy milk"
}

The request has two layers:

POST /todos                 ← intent
Content-Type: JSON          ← description

{ "text": "Buy milk" }     ← payload

The server might answer:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": "todo_123",
  "text": "Buy milk",
  "completed": false
}

The client asked for a new thing. The server returned the thing as it now exists.

---

HTTP forgets

HTTP is stateless.

That means each request arrives alone.

Request 1: "Who am I?"
Request 2: "Who am I?"
Request 3: "Who am I?"

The server does not remember merely because you asked before. So applications add memory explicitly:

Cookie           "This is the same browser as before."
Session          "This browser belongs to user 42."
Bearer token     "This request is authorized."
Database row     "The todo still exists."

HTTP itself is forgetful. Applications build remembering on top.

---

HTTPS is the same conversation, whispered

HTTP:

Browser ── plain message ──▶ Server

HTTPS:

Browser ── encrypted message ──▶ Server

Same request. Same response. But outsiders cannot read or rewrite the message in transit.

---

The useful picture

If you can see this, you understand most of HTTP:

┌────────────── request ──────────────┐
│ method:  POST                       │
│ path:    /todos                     │
│ headers: Content-Type: JSON         │
│ body:    { "text": "Buy milk" }    │
└─────────────────────────────────────┘
                  │
                  ▼
              server work
                  │
                  ▼
┌────────────── response ─────────────┐
│ status:  201 Created                │
│ headers: Content-Type: JSON         │
│ body:    { "id": "todo_123", ... } │
└─────────────────────────────────────┘

HTTP is a tiny ritual:

Say what you want.
Say what you got.
Repeat.

http-explainer.md

A Little HTTP Explainer

HTTP — Hypertext Transfer Protocol — is the language web browsers, apps, APIs, and servers use to talk to each other.

The basic idea

An HTTP interaction has two parts:

1. Request — the client asks for something.
2. Response — the server answers.

For example, when you open a web page, your browser sends a request like:

GET /docs HTTP/1.1
Host: example.com

And the server responds with something like:

HTTP/1.1 200 OK
Content-Type: text/html

<html>...</html>

Requests

A request usually contains:

• Method — what action you want.
• URL/path — what resource you want.
• Headers — metadata about the request.
• Body — optional data sent to the server.

Common methods:

• GET — read something.
• POST — create or submit something.
• PUT — replace something.
• PATCH — partially update something.
• DELETE — remove something.

Example API request:

POST /api/todos HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <token>

{
  "text": "Buy milk"
}

Responses

A response usually contains:

• Status code — whether the request succeeded.
• Headers — metadata about the response.
• Body — the actual content or data.

Common status codes:

• 200 OK — success.
• 201 Created — something was created.
• 204 No Content — success, but no response body.
• 400 Bad Request — the request was invalid.
• 401 Unauthorized — authentication is missing or invalid.
• 403 Forbidden — authenticated, but not allowed.
• 404 Not Found — resource does not exist.
• 500 Internal Server Error — server crashed or failed unexpectedly.

Example JSON response:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": "todo_123",
  "text": "Buy milk",
  "completed": false
}

Headers

Headers are key-value metadata.

Examples:

Content-Type: application/json
Accept: application/json
Authorization: Bearer abc123
Cache-Control: max-age=60

They tell the other side things like:

• what format the body uses;
• what formats the client accepts;
• whether the request is authenticated;
• whether the response can be cached.

Bodies

The body carries data.

A GET request usually has no body. A POST, PUT, or PATCH request often does.

Common body formats:

• JSON
• HTML
• plain text
• form data
• binary files

HTTP is stateless

Each request is independent. The server does not automatically remember previous requests.

Apps add continuity using things like:

• cookies;
• sessions;
• bearer tokens;
• request IDs;
• database state.

HTTPS

HTTPS is HTTP over TLS encryption.

It protects against people on the network reading or modifying traffic. In production, nearly all HTTP traffic should use HTTPS.

Mental model

Think of HTTP like sending a structured message:

Client: “Please GET /todos and I accept JSON.”
Server: “200 OK, here is JSON.”

Or:

Client: “Please POST /todos with this JSON body.”
Server: “201 Created, here is the new todo.”

That request-response loop is the foundation of the web.