In a server-side web framework, what does registering a route mean, and what do route groups and prefixes give you?

Route registration is the step where a web framework learns that a particular combination of request method and path template should be served by a particular piece of your code. It happens once, while the application is being built or started, and it produces a data structure — the **routing table** — that the framework consults for every request afterwards. Writing a handler function does not register anything: the handler is unreachable until some declaration puts it into that table. ## Registration is a separate step from handling Two things exist independently, and confusing them is the classic beginner bug: - The **handler** — your code, which receives a request-shaped object and produces a response. - The **registration** — the statement that requests matching this method and this path template go to that handler. Keeping them separate is what lets a framework do useful work before the first request: build an index of templates, detect two registrations that claim the same method and template, print an inventory of every route, and fail loudly at startup rather than returning a surprised `404` in production. ## The three places a URL can come from Frameworks differ in *where you write the declaration*, but all three styles end in the same table: 1. **Metadata attached to the handler** — a marker sits next to the function or method and the framework discovers it by scanning candidates at startup, or ahead of time during the build. 2. **An explicit registration call** — you write ordinary code that calls a register function, and the route table is a value you can read, order, compose and test. 3. **A convention over layout** — the directory tree and file names *are* the declaration, in a different medium: the framework derives the path from the layout by rule, so no separate statement exists in code. ## Templates, not literal paths A registration almost always carries a **template** such as `/orders/{id}`, with named variables, rather than a literal path. Registration's job is to put that template in the table together with its method; deciding which template wins for a concrete incoming path is a separate concern handled at request time. ## Groups and prefixes As a service grows, the same leading segments repeat on every line. A **group** declares them once and concatenates them at declaration time: | Without a group | With a group prefixed `/orders` | |---|---| | `route("GET", "/orders", list)` | `route("GET", "/", list)` | | `route("POST", "/orders", create)` | `route("POST", "/", create)` | | `route("GET", "/orders/{id}", show)` | `route("GET", "/{id}", show)` | | `route("GET", "/orders/{id}/items", items)` | `route("GET", "/{id}/items", items)` | What the group actually changes: 1. **One prefix, one edit.** Moving the whole subtree from `/orders` to `/v2/orders` is a single change instead of one per line, and there is no chance of mistyping one of them. 2. **Shared hooks in one place.** Cross-cutting behaviour attached to the group applies to everything declared inside it, so a newly added route inherits it by default instead of by remembering. 3. **Nesting.** Groups usually nest, so a prefix can be assembled from several levels, and a whole sub-tree can be declared in its own module and attached at the root. 4. **Declaration scope only.** A group does not rewrite incoming requests, open another port, or start another server. It is bookkeeping performed while the table is built. ## Traps a first service hits - **The handler nobody registered.** In discovery-based styles a handler in a place the scan does not look silently has no route; the symptom is a `404` for code you can see. - **The duplicated prefix.** Repeating `/orders` on every line survives until one line says `/order` and only that endpoint breaks. - **The double slash.** Concatenating a group prefix ending in `/` with a route beginning with `/` can produce `//{id}`; most frameworks normalise it, some do not. - **Forgetting that the method is part of the key.** A registration binds a method *and* a template, so declaring only one method leaves the others to the framework's default handling of a known path with an unsupported method. - **Assuming order of declaration is irrelevant.** It is a registration-time property you control, and it is worth keeping deliberate and reviewable. - **Mounting by copying.** Repeating a whole subtree under a second prefix instead of declaring it once and attaching it twice doubles every future edit. The mental model to carry away: registration fills a table before traffic; groups and prefixes are how you keep that table readable once it holds hundreds of rows.