Web Framework Concepts

One dispatch runs in order: resolve the route, run pre-handler hooks, bind the request into handler inputs, invoke the handler, render what it returned, then unwind the post-handler hooks. A failure at any stage diverts to the error stage instead.

Path variables come from the matched route template, so they exist whenever the handler runs. Query parameters and headers come from the client, so either may be missing or repeated, which is why frameworks expose both single- and multi-value accessors.

An HTTP response carries its status line and header block ahead of the body, so the framework sends them first. Once body bytes are flushed the response is committed, and later status, header or cookie changes are lost.

A static path matches one exact sequence of literal segments. A template such as /orders/{id} matches any single segment in that position and captures its text as a named path variable the handler can read.

Registering a route binds an HTTP method and path template to a handler in the routing table before requests arrive. A group registers many routes under a shared prefix and shared hooks, writing the common part once.

The chain stops there: nothing inward of that hook is entered, so the handler never runs. The error unwinds outward through the hooks already entered, in reverse, and the outermost error stage turns it into a response.

Each element wraps the entire remainder of the chain as one callable. It receives the request, may act on it, then explicitly invokes that remainder; if it never invokes it, the request never reaches the handler.

A correlation id must exist before anything downstream writes a log line, records a metric or calls another service, so the hook that adopts or generates it runs first. Anything registered ahead of it emits records nothing can join.

A hook running before routing sees the raw message and the connection: method, request-target string, headers, client address, an unread body. The route template, path variables, handler, bound arguments and return value do not exist yet.

By default, registration order is inbound execution order: the first hook registered becomes the outermost layer and runs first, each one delegating inward, with the matched route handler innermost and running last.

The Content-Type request header names the format, and the framework picks a body parser from it. A JSON body is one nested, typed value; a form-encoded body is a flat, percent-encoded list of string key/value pairs.

A multipart/form-data body is a run of boundary-delimited parts, each with its own headers naming the form field and, for files, a filename. The framework walks them in arrival order as field values or file handles.

Handler parameters bind from captured path segments, the query string, headers, cookies, form fields, or the parsed body. The framework picks the source from an explicit marker on the parameter, or infers it from the parameter's name and type.

The returned value models the body, not the whole response. The framework picks a writer for the negotiated media type, serializes the value, synthesises Content-Type and framing, then applies a default success status, conventionally 200.

A URL carries only text. The binder finds a converter for the parameter's declared type, runs it on the raw string, and passes the result in. A failed conversion ends the request as a client error before the handler runs.

A lifetime decides how long the container reuses one instance. A singleton lives as long as the process and serves every request; one per-request instance serves a single request; a transient is built fresh at every resolution.

A dependency-injection container is a registry of construction recipes: you register how each service is built, then ask for one and it builds the whole graph behind it. Handlers declare collaborators as constructor parameters and the container supplies them.

Installing a plugin runs its registration code against the application at startup: it adds components to the object graph, attaches request-pipeline hooks, and contributes overridable defaults. It is wiring executed once, not a per-request call.

Settings are read and validated first, then the object graph is built, then routes and middleware are registered, and only then is the listening socket bound. Binding last keeps traffic out until the application can serve it.

The singleton is built once and keeps whatever it was given, so a per-request dependency is captured from the first request and reused forever. Later requests then read the first request's state, which only shows up when requests overlap.

A collection of violation records, not one error. Each carries the property path that failed, the value that was rejected, the identity of the constraint that rejected it, and a message key with its parameters.

Declared constraints are metadata the framework reads and enforces on the bound model before the handler body runs, so the rule lives beside the field it describes and every endpoint binding that model inherits it.

A naming strategy is the rule that converts property names in code into key names in the document, and back on read. Setting it on the shared serializer makes one decision cover every payload instead of repeating it per field.

Declare the exclusion on the model the mapper serializes: mark the field write-only or ignored on output, or better, use a response model that has no such field at all. Do not strip it per handler.

A view resolver maps a logical view name onto a concrete template, usually by adding a configured prefix and suffix and searching ordered locations; the engine then executes that template with the model as its variable scope.

The framework's own fallback answers with 404 Not Found, and no handler of yours runs. Routing finds no match, so the request falls through to the built-in default error response, rendered as a page or as a structured body.

A central registry maps failure types to HTTP statuses in one place: the framework catches whatever a handler throws, looks up the closest registered type, and runs that mapper to build the response. Route code stays free of transport concerns.

Once the status line and headers are flushed to the socket, nothing can retract them; HTTP has no take-back. A mapper running afterwards can only append to the body, emit a trailer, log the failure, or abort the connection.

Two rendering modes of one fallback, chosen by a flag, not by the failure. Development mode prints the failure type, message and stack for the author; production mode prints a status and short message so internals never reach untrusted callers.

Most frameworks resolve by specificity: they walk the thrown type's ancestry and pick the nearest registered ancestor, so a subtype registration beats a base-type one. Where the registry is a scanned list of predicates, the first match wins and registration order decides.

Read helpers parse the inbound Cookie header into name-value pairs, with no attributes attached. Write helpers append one Set-Cookie header per cookie and fill anything the call site omits from the application's configured cookie defaults.

A locale resolver runs early in each request and takes the first source that yields a supported locale: a URL marker, a stored preference in a cookie or session, the client's language header, then a configured default.

A per-request attribute bag is a mutable key/value map the framework creates when a request arrives and discards when it completes. Earlier stages write entries into it; the handler and later stages read them, so derived values travel without extra parameters.

Flash scope holds a value written on one request and exposed to the next, after which the framework discards it without any delete call. A plain session attribute stays until code removes it, so it would reappear on later pages.

A delete helper erases nothing: it writes the cookie name back already expired. The client drops a stored cookie only when name, domain and path all match, so a deletion using the framework's default scope misses a differently scoped cookie.

The handler returns a handle to a response that does not exist yet. The framework leaves the exchange open, attaches a completion callback, and writes status, headers and body only once that handle completes with a value.

Thread-per-request frameworks give each request a pooled worker thread for the whole exchange. Event-loop frameworks run handlers as short turns on a few shared loop threads. Coroutine frameworks suspend the handler at await points and release the carrier thread meanwhile.

Streaming keeps memory flat and bytes moving. The handler writes pieces the framework sends as they are produced, so a large response costs a small buffer per request instead of its full size, and the client sees data sooner.

A request timeout bounds how long the framework waits for a response, not how long the handler runs. When it fires, the framework abandons the result and writes an error response; the handler usually keeps executing.

A failed awaitable is delivered to the framework's error-mapping stage, the same one that handles a thrown error, and becomes an error status. An awaitable that never settles produces no response at all: the exchange stays open holding its resources.

A test that always sends a valid credential passes even when the route is not protected at all. The credential-free request is the case that proves a guard is actually wired on that route and answers before the handler runs.

An in-process test client builds a request in memory and hands it to the framework's dispatcher, then captures the response as an object. No socket and no port: the call is an ordinary method call in the test process.

Call the hook directly with a hand-built request and a recording stub in place of the next element. The stub captures whether it was invoked and with which request, so the test can assert delegation without starting a server.

It proves only the handler body: its branches, its return value, its exceptions. Route matching, request binding, the hook chain, response serialisation and status or header mapping never run, because no framework was started.

Contribute a replacement registration for that boundary into the configuration the container reads, so the graph is built with the stand-in. Constructing it by hand affects only your own object, not the one the framework injects into handlers.