HTTP Request-Response Cycle

1. What Is It?

HTTP (HyperText Transfer Protocol) is the application-layer protocol that powers the web and the vast majority of API communication. It defines a simple request-response model: a client sends a request message, a server processes it, and the server sends back a response. Every REST API, every browser page load, and most microservice communication runs on HTTP.

The problem HTTP solves: applications need a standard way to exchange structured messages across a TCP connection. HTTP defines message format, verbs (GET, POST, PUT, etc.), status codes, and headers — giving both sides a common language without needing custom framing logic.

2. How It Works

Request Anatomy

GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbG...
Accept: application/json
Connection: keep-alive

• Method — the verb: GET (read), POST (create), PUT/PATCH (update), DELETE (remove), HEAD (headers only), OPTIONS (CORS preflight).
• Path — the resource identifier. Query string (?key=value) is part of the path.
• HTTP version — HTTP/1.1 (or HTTP/1.0). HTTP/2 has no text request line. It sends the method and path as binary pseudo-headers (:method, :path).
• Headers — key-value metadata: authentication, content type, caching directives, encoding.
• Body — optional payload, typically JSON or form-encoded data (present in POST/PUT/PATCH, absent in GET/DELETE).

Response Anatomy

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 57
Cache-Control: max-age=60

{"id": 42, "name": "Alice", "email": "alice@example.com"}

• Status line — protocol version + status code + reason phrase.
• Headers — server metadata: content type, length, caching, CORS, cookies.
• Body — the payload.

Full Cycle

For a single https:// request, the network path is: DNS lookup → TCP handshake → TLS handshake → HTTP request → response. This is 3–4 round trips before data arrives. HTTP persistent connections (Connection: keep-alive) reuse the TCP+TLS session for subsequent requests, eliminating the handshake overhead.

3. What SDEs Actually Need to Know

Status codes by class:

The 401 vs 403 distinction:

• 401 Unauthorized — credentials are missing or invalid. "Who are you?"
• 403 Forbidden — credentials are valid but the user lacks permission. "I know who you are, but you can't do this."

Idempotency:

• GET, PUT, DELETE, HEAD are idempotent — calling them multiple times has the same effect as calling once. Retrying them is safe.
• POST is not idempotent by default — retrying a POST may create duplicate records. Use idempotency keys (e.g., Stripe's Idempotency-Key header) to make POST retries safe.

Headers SDEs interact with most:

• Content-Type — declares the payload format (application/json, multipart/form-data, etc.). Mismatch causes 415 Unsupported Media Type or parsing failures.
• Authorization — carries credentials: Bearer <token>, Basic <base64>, AWS4-HMAC-SHA256 ....
• Cache-Control — controls caching behavior for CDNs and browsers. no-cache, no-store, max-age=N.
• X-Request-ID / X-Trace-ID — correlation IDs for tracing requests across services. Not standard but universal in production systems.

Connection management:

• HTTP/1.1 defaults to persistent connections (keep-alive). The server closes them after keepalive_timeout (default 75s in nginx, but the stock nginx.conf sets 65s).
• Sending Connection: close forces the server to close after the response — useful if you need guaranteed connection cleanup.
• Keep-alive connections are pooled by the HTTP client library (for example requests.Session or OkHttp), not by the OS. In high-throughput services, MAX_CONNECTIONS and connection pool sizing matter.

4. Tradeoffs & Decisions

HTTP method semantics in API design: Using methods correctly lets clients (and intermediaries like CDNs) make safe assumptions. GET requests can be cached; POST requests cannot. DELETE requests can be retried; POST requests typically cannot without idempotency keys. Violating these semantics — like using POST for all reads — breaks caching, monitoring, and client retry logic.

Chunked transfer encoding vs. Content-Length:

• Content-Length — client knows the response size upfront, which is efficient. A server can stream a body of known size (a static file). But for generated content, it must buffer the entire response to compute it.
• Transfer-Encoding: chunked — server streams data in pieces without knowing the total size. Better for large responses (file downloads, streaming data). Intermediate proxies must handle chunked encoding properly.

Compression: Accept-Encoding: gzip, br tells the server the client can handle compressed responses. JSON APIs can see 60–80% size reduction with gzip. The cost is CPU time for compression/decompression and slightly increased time-to-first-byte for small responses. Enable for API responses > ~1KB; disable for small responses and pre-compressed content (images, video).

5. Interview Cheat Sheet

Key sentences:

• "HTTP is a request-response protocol over TCP: client sends a message (method + path + headers + optional body), server responds (status + headers + body)."
• "Before a single byte of HTTP data flows over HTTPS, there's a DNS lookup, a TCP handshake, and a TLS handshake — totaling 3–4 round trips. Persistent connections amortize this."
• "Status codes are grouped: 2xx success, 3xx redirect, 4xx client error, 5xx server error. 401 means unauthenticated; 403 means unauthorized."
• "GET/PUT/DELETE are idempotent; POST is not — retrying a POST without idempotency keys can create duplicate side effects."

Common follow-ups:

Q: What's the difference between PUT and PATCH? A: PUT replaces the entire resource — you send the full updated representation. PATCH applies a partial update — you send only the fields to change. PUT is idempotent and semantically cleaner for full replacements; PATCH is more efficient for partial updates on large resources.

Q: What happens when a browser sees a 301 vs. 302 redirect? A: Both redirect the client to a new URL via the Location header. 301 (Moved Permanently) tells the browser to update bookmarks and send future requests directly to the new URL; the redirect is cached indefinitely. 302 (Found / Temporary Redirect) means the original URL is still authoritative; the browser follows the redirect but doesn't cache it.

Q: How does HTTP caching work? A: The server sends Cache-Control headers that tell clients and intermediaries (CDNs, proxies) how long to cache a response. max-age=3600 means cache for 1 hour. ETag and Last-Modified enable conditional requests: the client sends If-None-Match or If-Modified-Since; if the resource hasn't changed, the server responds 304 Not Modified with no body, saving bandwidth.