The protocol behind 90% of the internet. You've spoken it your whole life without realizing — and underneath, there's a careful little ceremony happening every time you load a page. Time to read the script.
Most people think HTTP is some elaborate binary protocol — magic happening on the wire that only computers understand. It isn't. HTTP is one of the most readable things in computing: literal ASCII text sent over a TCP connection. If you opened a wiretap and looked at what your browser sends, you'd see something like this.
That's it. That's the entire request your browser just sent to load a page. A verb, a path, some headers as key-value pairs, a blank line — done. The server reads that text, does some work, and writes back a similar block of text containing the page. HTTP is text. Once you internalize that, half of "backend" stops being mysterious.
The client sends a request. The server sends a response. Both have the same shape: a one-line summary, a block of headers, a blank line, and (sometimes) a body. Learn this skeleton and you can read any HTTP traffic in the world.
The start line says what you want (request) or what happened (response). Headers are metadata — who's talking, what format, what encoding, what authorization. The body is the actual payload — JSON, HTML, an image, a file. Many requests have no body (a GET asking for a page). Many responses have huge bodies (an HTML document). Same shape either way.
You'll see HTTP/1.1, HTTP/2, and HTTP/3 on those start lines. The underlying ceremony of methods, headers, and bodies is the same across all three — the differences are about how the bytes are framed and multiplexed on the wire. For now, ignore the version number; the rules don't change.
HTTP has many methods, but in practice you'll use five. Each one tells the server what kind of action you want. Click any card to expand — pay attention to the traits at the bottom (safe, idempotent, has body). Those distinctions matter when things go wrong.
Ask the server to return a resource. Should never modify anything. The most common HTTP method by far — every page load is a flurry of GETs.
Send data to the server to create a new resource — a comment, a transaction, a user. Repeating a POST usually creates duplicates, so handle it carefully.
Send a complete resource to a specific URL — replacing whatever was there. Used when you know the exact identity of the thing you're writing.
PUT /users/42 says "user 42 should now look like this." Repeating it gives the same result — that's idempotent. Safe to retry on network failures.
Ask the server to delete a resource at a specific URL. Sounds dramatic; it's just like any other method, just with destructive intent.
Like PUT, but you only send the fields you want to change. The diff, not the whole document. Useful when the resource is big and you're tweaking a small thing.
PATCH /users/42 { "email": "new@x.com" } updates only the email. Not strictly idempotent in all cases (depends on payload), so use with care.
HEAD (like GET but no body — for checking if a resource exists). OPTIONS (asks the server what's allowed — used for CORS preflights). TRACE and CONNECT are even rarer.
The key concepts to walk away with: safe means it doesn't change anything on the server. Idempotent means doing it twice has the same effect as doing it once. These two properties decide whether it's OK to retry a request after a network blip — which is one of the most common decisions in real backend code.
Pick a scenario below and you'll see the exact bytes that travel between client and server. Click any line in the request or response to get an explanation of what it does and why it's there. This is the single most valuable habit you can build as a backend engineer — actually reading the protocol.
Each line in HTTP has a job. Click a line above to see what it does, why it's there, and what would happen if you removed it. Try the status line — it tells you everything in 3 characters.
HTTP is plain text. Anyone with the right tools — your coffee shop's WiFi, your ISP, a router operator — can read it. HTTPS solves this with one elegant trick: before any actual HTTP is exchanged, the client and server perform a handshake to agree on a shared secret. After the handshake, everything is encrypted. Press Play handshake below to watch it.
The browser opens the conversation by sending a "ClientHello" — basically a list of: which TLS versions it supports, which encryption ciphers it understands, and a random number. It's the browser saying "here's everything I can do — pick something."
Notice what just happened: at no point did the actual HTTP request go out in plain text. Before the browser even sent GET /, the two sides verified each other's identity (via certificates), agreed on encryption, and established a shared secret. The whole HTTP exchange afterwards rides through an encrypted tunnel. That's all "the S" really is. No magic — just a polite ceremony that happens to be cryptographically rock-solid.
Each one of these will appear in interviews, design docs, and incident reports for the rest of your career. Burn them in.
Content-Type, Authorization, Cookie — all headers. Cheap to add; powerful in effect.2xx = ok, 3xx = redirect, 4xx = your fault, 5xx = server's fault. Memorize the ranges.application/json, text/html, image/png. Tells the receiver how to parse what came in.Locking in what you read on the wire. Tap an answer; explanation appears instantly.
You read HTTP now. Most engineers never quite get there.
You can now read what your browser is whispering. Use it.
Start line, headers, blank line, body. Same shape for requests and responses. Read it like a letter, not a spell.
GET reads, POST creates, PUT replaces, DELETE removes, PATCH modifies. Idempotency tells you when it's safe to retry.
The "S" is a quick handshake before any data flies. Same protocol on top — just wrapped in a cryptographic tunnel.