HTTP, HTTPS & the Request Lifecycle
The actual conversation format every browser and server uses — and the encryption layer that keeps it private.
1.8.1Definition
HTTP (HyperText Transfer Protocol) is the application-level protocol that defines how a client asks a server for something and how the server structures its reply — a shared grammar of requests and responses. HTTPS is the same protocol wrapped in an encryption layer (TLS), so the contents of that conversation can't be read or tampered with by anyone intercepting the traffic in between.
1.8.2The Request Lifecycle
A single HTTP exchange follows a consistent shape: the client sends a method (what kind of action — GET to retrieve, POST to create, PUT/PATCH to update, DELETE to remove), a path (which resource), headers (metadata like content type or authentication), and optionally a body (the actual data being sent, for POST/PUT). The server responds with a status code (a standardized signal of what happened — success, client error, server error), its own headers, and typically a body containing the requested content or result.
+ data
1.8.3Status Code Families
| Range | Meaning |
|---|---|
| 2xx | Success — the request was understood and completed (200 OK, 201 Created) |
| 3xx | Redirection — the resource has moved elsewhere |
| 4xx | Client error — the request itself was invalid (404 Not Found, 401 Unauthorized) |
| 5xx | Server error — the request was valid, but the server failed to fulfill it |
1.8.4Common Mistakes
- Misusing status codes. Returning 200 OK for a request that actually failed, forcing every client to parse the response body just to know if something went wrong — defeating the purpose of a standardized status layer.
- Sending sensitive data over plain HTTP. Any data sent unencrypted can be read or altered in transit; HTTPS is not optional for anything involving credentials, personal data, or payments.
- Using GET for actions that change data. GET requests are expected to be safe to repeat, cache, and prefetch — using them to trigger deletions or state changes can cause accidental data loss from caching or prefetching behavior.
1.8.5Best Practices
- Use HTTPS for everything, without exception — it is no longer meaningfully more expensive or complex than plain HTTP.
- Match HTTP methods to their intended semantics (GET reads, POST creates, PUT/PATCH updates, DELETE removes) so the protocol's own structure communicates intent.
- Return status codes that accurately reflect the outcome, and keep response bodies consistent in shape for a given status family.