HTTP Protocol

Anatomy of requests, methods, status codes, and the headers you must know.

HTTP in Plain Terms

HTTP (HyperText Transfer Protocol) is the language that clients and servers use to talk to each other. Every API call, every web page load, every webhook — all HTTP.

It's a request-response protocol: the client sends a request, the server sends one response. That's it. HTTP itself is stateless — the server has no memory of previous requests unless you build that in yourself (cookies, sessions, tokens).

Anatomy of an HTTP Request

An HTTP request has four parts:

1. REQUEST LINE — Method + Path + Version
   GET /users/123 HTTP/1.1

2. HEADERS — Key-value metadata
   Host: api.example.com
   Authorization: Bearer <token>
   Content-Type: application/json
   Accept: application/json

3. BLANK LINE — Separates headers from body

4. BODY — The payload (only for POST, PUT, PATCH)
   {"name": "Alice", "email": "alice@example.com"}

The server reads this top to bottom, parses it, and routes based on method + path.

HTTP Methods

GET — Retrieve a resource. No body. Should be idempotent (same result every time).
POST — Create a resource. Has a body. Not idempotent.
PUT — Replace a resource entirely. Idempotent.
PATCH — Partially update a resource. May or may not be idempotent.
DELETE — Remove a resource. Idempotent.
HEAD — Like GET but returns only headers (useful for checking if a resource exists).
OPTIONS — Returns what methods are allowed on a resource (used by CORS preflight).

The "safe" methods (GET, HEAD, OPTIONS) should never change server state.
The "idempotent" methods (GET, PUT, DELETE) produce the same result no matter how many times you call them.

Status Codes

Status codes tell the client what happened:

2xx — Success
  200 OK           — Request succeeded
  201 Created      — Resource created (after POST)
  204 No Content   — Success but no response body (after DELETE)

3xx — Redirects
  301 Moved Permanently  — New permanent URL
  302 Found              — Temporary redirect
  304 Not Modified       — Use your cached version

4xx — Client Errors (the client did something wrong)
  400 Bad Request        — Malformed request / validation error
  401 Unauthorized       — Not authenticated
  403 Forbidden          — Authenticated but no permission
  404 Not Found          — Resource doesn't exist
  409 Conflict           — Duplicate resource / version conflict
  422 Unprocessable      — Validation failed (semantic error)
  429 Too Many Requests  — Rate limited

5xx — Server Errors (our fault)
  500 Internal Server Error  — Something broke on our end
  502 Bad Gateway            — Upstream service failed
  503 Service Unavailable    — Overloaded or down for maintenance

HTTP Versions

HTTP/1.1 — One request per TCP connection (keep-alive extended this). Still dominant.

HTTP/2 — Multiplexing: multiple requests over one connection simultaneously. Header compression. Server push. Major performance boost.

HTTP/3 — Built on QUIC (UDP-based). Eliminates head-of-line blocking. Used by major platforms today.

As a backend engineer, you mostly write HTTP/1.1-style code, but your infrastructure (Nginx, CDN) handles protocol negotiation. Understanding the differences helps with performance tuning.

Headers You Must Know

Content-Type — Describes the format of the body (application/json, text/html)
Accept — What formats the client can handle
Authorization — Credentials (Bearer <token>, Basic <base64>)
Cache-Control — Caching directives (no-cache, max-age=3600)
CORS Headers — Cross-origin resource sharing control
ETag — Resource version identifier for conditional requests
X-Request-ID — Unique ID for tracing a request through logs
Set-Cookie — Server sets a cookie on the client
Cookie — Client sends stored cookies back