HTTP / HTTPS

In March 1989, Tim Berners-Lee at CERN wrote a proposal titled "Information Management: A Proposal." His boss wrote on the front page: "Vague, but exciting." A year later, Berners-Lee had built three things: a URL scheme (so documents could reference each other), an HTML markup language (so documents had structure), and a small protocol that let one computer ask another for a document. He called that protocol HTTP — HyperText Transfer Protocol. The first version had one method, no headers, no status codes, and transferred exactly one document per connection. It was ~30 lines of specification.

Today HTTP is the transport for effectively the entire internet. Your bank runs on HTTP. Netflix runs on HTTP. gRPC runs on HTTP. Your smart lightbulb runs on HTTP. It moves ~7,500,000 GB/s globally — and every one of those requests is a variation on the same pattern Berners-Lee sketched in 1990: "Hey server, please give me this document. Here's some context. Signed, this client."

Understanding HTTP is not optional if you want to design systems. Every design interview will assume you know: the request lifecycle (what happens betweenyou type a URL and the page renders), the methods (GET vs POST vs PUT vs PATCH vs DELETE — and why idempotency matters), the status codes (what 301 vs 302 vs 307 vs 308 actually mean for cache behavior), headers (Cache-Control, ETag, Content-Encoding), and HTTPS (how TLS wraps HTTP so nobody in the middle can read your bank transfer).

The request lifecycle — what happens when you type a URL

You type https://example.com/page and hit enter. Between that moment and the page rendering, at least 6 distinct network operations happen — and if any one of them is slow, your page is slow. Watch the full request lifecycle:

The critical insight: your page-load latency is the sum of every step above — DNS lookup, TCP handshake, TLS handshake, HTTP request, server processing, response transmission, parsing, rendering. Optimizing any single step (say, TLS session resumption to skip the handshake) speeds up every request that follows. This is why CDNs, HTTP/2, HTTP/3, and 0-RTT TLS exist: compress the timeline.

HTTP methods — the verbs

HTTP is REST's foundation because it's verb-based — the URL is the noun (the resource), the method is what you want done to it. There are 9 methods, but 5 of them do the vast majority of work. Two properties matter for every method: safety (does it modify state?) and idempotency (does calling it N times have the same effect as calling it once?).

Idempotency is the property that lets you retry safely. Network blips are constant — a client sends PUT, gets a timeout, and doesn't know if the write landed. If PUT is idempotent, the client just retries; the second call is a no-op if the first succeeded. POST doesn't have this property — retry a "charge card" POST and you charge twice. This is why every payment API in the world uses Idempotency-Key headers to fake idempotency onto POST.

Status codes — what the server says back

Every HTTP response starts with a 3-digit status code. The first digit is the class: 1xx informational (rarely seen), 2xx success, 3xx redirect, 4xx client error, 5xx server error. Understanding the details — especially the redirect codes and the difference between 401 and 403 — is a common interview filter.

The 301 vs 302 vs 307 vs 308 gotcha — permanence AND method preservation

This is the most common HTTP question in every interview. The 4 redirect codes look interchangeable but they mean subtly different things:

• 301 Moved Permanently — the resource has movedforever. Browsers cache the redirect. Search engines update their index. Historically, browsers were also allowed to change POST → GET on the redirect (a spec quirk).
• 302 Found — the resource is temporarily at a different URL. Do not cache. Historically browsers also allowed POST → GET on this one.
• 307 Temporary Redirect — same as 302, but must preserve the original method. POST stays POST. This is what "temporary redirect" should have always meant.
• 308 Permanent Redirect — same as 301, but must preserve the original method. POST stays POST. The modern "permanent" redirect.

Modern APIs use 308 when they change a permanent URL and 307 when they want a temporary redirect that preserves POST/PUT method. 301 and 302 still exist but their method-changing behavior is a landmine for POST-based APIs.

Who actually uses which code in production — the interview cheat sheet

The RFCs define semantics. Production systems reveal what those semantics buy in practice. Study this table before the interview — it's what separates candidates who read RFCs from candidates who've operated infrastructure:

HTTP vs HTTPS — what the S actually does

HTTPS is HTTP running on top of TLS instead of raw TCP. Same protocol, same methods, same headers — but the whole thing is encrypted and authenticated. Watch what changes in the request flow:

Three properties come from TLS: confidentiality (nobody in the middle can read the request), integrity (nobody can modify it undetected), and authentication (via certificates, the client knows it's really talking to example.com). Since 2020 essentially all major browsers refuse to load plain HTTP by default; Chrome, Firefox, and Safari all warn users aggressively. HTTPS-everywhere is now the assumption.

Key HTTP headers you must know

HTTP version timeline — a 35-year evolution

Applied in real systems

HTTP is the connective tissue. Every system below made explicit choices about which HTTP version, which methods, which cache headers.

Key takeaways

• Every HTTP request is DNS lookup → TCP handshake → (TLS handshake if HTTPS) → HTTP request → server processing → response → parse → render. Latency = sum of all steps.
• HTTP methods split by safety (does it modify state) and idempotency (can I retry safely). GET/HEAD/OPTIONS are safe; GET/PUT/DELETE are idempotent; POST is neither.
• For redirects: 301 = permanent + may change method, 302 = temporary + may change method, 307 = temporary + method-preserving, 308 = permanent + method-preserving. Use 307/308 for modern APIs.
• 401 vs 403: 401 "I don't know who you are" (please authenticate); 403 "I know who you are, you can't do this" (permission denied). Get this right on your APIs — clients handle them differently.
• HTTPS = HTTP over TLS. Same protocol, wrapped in confidentiality + integrity + authentication. As of 2024 essentially all major browsers require HTTPS by default.
• The big cache headers are Cache-Control, ETag, Last-Modified, Vary. Together they let a CDN serve 95%+ of your traffic without hitting origin.
• HTTP versions: 0.9 (1991) → 1.0 (1996) → 1.1 (1999) → 2 (2015) → 3 (2022). Each solved the previous version's biggest bottleneck.

References

• Berners-Lee (1991) — Original HTTP/0.9 proposal at CERN.
• RFC 2616 (1999) — HTTP/1.1. The definitive version for 16 years.
• Fielding (2000) — "Architectural Styles and the Design of Network-based Software Architectures." PhD thesis. Defines REST.
• RFC 7540 (2015) — HTTP/2. Multiplexing over binary framing.
• RFC 9110 (2022) — HTTP Semantics. The unified modern reference.
• RFC 9114 (2022) — HTTP/3. QUIC-based transport.
• Grigorik (2013) — High Performance Browser Networking. Free online. The best deep-dive on the request lifecycle.