Lectures

We break down how the middleware chain is built in net/http around http.Handler: the base contract ServeHTTP, the “before → next → after” scheme, short-circuiting (when a request is not allowed to continue), and why the order in the chain looks like A(B(C(H))). We write a Chain helper that applies middleware in reverse order, and we lock in the typical mistakes made when assembling and applying chains.

We’ll break down why an HTTP service needs a request_id, how to agree on a mini-contract for the X-Request-ID header, why a request identifier should be stored in context.Context, how to correctly choose a key for context.WithValue, generate an id via crypto/rand, and how to build middleware that puts request_id into the context and returns it to the client in response headers.

We break down how to move API key validation into middleware, return correct statuses 401/ 403 and a single JSON error envelope, and also why configuration (for example, APP_API_KEY) must be validated at startup using the fail fast principle. We write minimal utilities on top of net/http and carefully assemble the chain via Chain.

We’ll break down a minimal rate limit for an HTTP API in Go: why it’s needed, how the fixed window model works with window/ limit parameters, how to choose a client key from r.RemoteAddr, why parallel requests require sync.Mutex, and how to wrap the limiter into middleware that responds with 429 and the Retry-After header.

We break down why you need recover() at the HTTP boundary: how to avoid “taking down” the server because of a panic in a handler, how to keep a stable API contract (a JSON error envelope with status 500), what and how to log via log/slog, why recover() works only inside defer, and how to correctly arrange the middleware order (including request_id).