HTTP and HTTPS Explained: What Every Web Developer Should Actually Know
Methods, status codes, headers, and what TLS is actually encrypting — the protocol underneath every fetch() call, explained past the memorized 200/404/500 list.
Every REST API call, every page load, every asset request runs over HTTP. Most developers know the common status codes by memory without knowing what's actually structurally underneath them — worth fixing, because the structure explains the codes rather than the other way around.
The actual shape of a request and response
A request has a method (GET, POST, PUT, PATCH, DELETE — each with a real, meaningful convention: GET shouldn't have side effects, PUT should be idempotent), a path, headers (metadata — content type, authorization token, caching directives), and optionally a body. A response mirrors that shape: a status code, headers, and a body.
Status codes, by what they actually mean, not by number
- 2xx — success. 200 OK is the general case; 201 Created specifically means a POST successfully made a new resource; 204 No Content means success with deliberately no body.
- 3xx — redirection. 301 is a permanent redirect (tell search engines and caches to update their records); 302 is temporary (don't update anything permanently).
- 4xx — the client did something the server won't accept. 400 is a malformed request; 401 means "who are you" (not authenticated); 403 means "I know who you are, and no" (not authorized); 404 is the famous one, a resource that doesn't exist at that path.
- 5xx — the server failed, not the client's fault. 500 is a generic server error; 503 specifically means temporarily unavailable, often used deliberately during maintenance.
What HTTPS actually adds
HTTPS is HTTP running over TLS (Transport Layer Security) — the same request/response model, with the entire exchange encrypted so a party intercepting the traffic (a coffee-shop Wi-Fi network, an ISP) sees ciphertext, not readable headers or bodies. It also gives you authentication — the certificate proves you're actually talking to the domain you think you are, not an impersonator — which is precisely what a fake WiFi hotspot exploits without it. Modern browsers actively flag plain HTTP sites as "not secure," and it's a hard prerequisite for several browser APIs (service workers, geolocation) that simply refuse to run over plain HTTP at all.