HTTP

HTTP is a stateless request/response protocol. A client sends a request; the server sends back a response. That's the whole model. No persistent connection state, no memory of previous requests unless the application explicitly stores it (e.g. in a session cookie or JWT).

Every HTTP interaction has the same shape:

---

Each method has a defined semantic meaning. Using the wrong one breaks caching, breaks idempotency, and confuses clients.

Method	Meaning	Idempotent	Has body
GET	Retrieve a resource	Yes	No
POST	Create a resource or trigger an action	No	Yes
PUT	Replace a resource entirely	Yes	Yes
PATCH	Partially update a resource	No	Yes
DELETE	Remove a resource	Yes	No
HEAD	Same as GET, but response body omitted	Yes	No
OPTIONS	Describe communication options (used in CORS preflight)	Yes	No

Idempotent means calling the same request multiple times produces the same result. GET /users/42 is idempotent: you can call it 100 times and nothing changes. POST /orders is not: each call creates a new order.

---

Status codes tell the client what happened. They are grouped into five classes:

Range	Class	Common examples
1xx	Informational	100 Continue, 101 Switching Protocols
2xx	Success	200 OK, 201 Created, 204 No Content
3xx	Redirection	301 Moved Permanently, 304 Not Modified
4xx	Client error	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests
5xx	Server error	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

The most common mistake: returning 200 OK with an error message in the body. A client should be able to detect success or failure from the status code alone, without parsing the body.

---

Headers carry metadata about the request or response. Key ones every backend engineer should know:

Request headers:

• Authorization: Bearer <token> — carries authentication credentials
• Content-Type: application/json — tells the server what format the body is in
• Accept: application/json — tells the server what format the client can handle
• Cache-Control: no-cache — controls caching behaviour

Response headers:

• Content-Type: application/json — describes the response body format
• Cache-Control: max-age=3600 — tells clients and proxies how long to cache this response
• ETag: "abc123" — a fingerprint of the response, used for conditional requests
• Location: /users/42 — returned with 201 Created, points to the new resource
• Retry-After: 60 — returned with 429, tells the client when to retry

---

Feature	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP	QUIC (UDP-based)
Multiplexing	No (one request per connection at a time)	Yes (many requests on one connection)	Yes
Header compression	No	HPACK	QPACK
Head-of-line blocking	Yes	Partial (TCP-level)	No
Typical use	Legacy systems	Current standard	Emerging (CDNs, mobile)

HTTP/1.1's biggest problem: head-of-line blocking. A slow response blocks all subsequent requests on the same connection. HTTP/2 solves this with multiplexing. In production, always prefer HTTP/2 or HTTP/3 if your infrastructure supports it.

---

HTTPS is HTTP with TLS (Transport Layer Security) encryption layered underneath. The TLS handshake happens before any HTTP bytes are sent:

1. Client sends a ClientHello with supported TLS versions and cipher suites
2. Server responds with its certificate (containing its public key)
3. Client verifies the certificate against a trusted Certificate Authority
4. Both sides derive a shared session key using asymmetric cryptography
5. All subsequent HTTP traffic is encrypted with that session key

In production: always use HTTPS. Never transmit credentials or sensitive data over plain HTTP. Use Strict-Transport-Security headers to prevent downgrade attacks.

---

• HTTP on MDN Web Docs — the most complete and readable HTTP reference available
• HTTP/2 explained — Daniel Stenberg's free book on HTTP/2
• How HTTPS works (cartoon) — the clearest visual explanation of TLS handshakes
• HTTP status codes reference — every status code with usage notes