In a server-side web framework, what does registering a route mean, and what do route groups and prefixes give you?
answer
- a table built before traffic arrives
- declaration is separate from the handler
- method plus path template maps to handler
- group means shared prefix and shared hooks
- prefix written once, not per line
basics
~20 sRegistering 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.
solid answer
~40 sRegistration is the declaration step. Before traffic arrives, the framework builds a table of `method + path template -> handler`, and your handler is invisible to the framework until something puts it there. You declare it by attaching metadata to the handler, by calling a registration function explicitly such as `route("GET", "/orders/{id}", handler)`, or by letting a convention derive the path from file or name layout. A **group** (also called a sub-router or scope) declares a set of routes under one prefix, so `/orders` and `/orders/{id}` become `/` and `/{id}` inside a group prefixed `/orders`, and hooks attached to the group apply to everything declared inside it. The payoff is one place to change the prefix and one place to attach cross-cutting behaviour, instead of repeating both on every line.
go deeper
Recall that a handler plus a registration are two separate things, and that a route is a method and a path template pointing at a handler. Know that a group declares a shared prefix once.
Explain when the table is built, why building it early enables duplicate detection and route listing, and exactly what a group concatenates versus what it leaves to request-time matching.
Show the operational payoff: startup-time conflict detection, a printable route inventory, and grouping used so that a newly added route inherits the right cross-cutting behaviour by default rather than by memory.
Frame it as a contract surface. The registration layer decides how discoverable your endpoint set is, how cheaply a prefix can move, and whether mistakes surface at boot or as production 404s.
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.
- What should happen when two registrations declare the same method and the same path template?It is a conflict that is visible at registration time, before any request arrives. Frameworks differ in policy — some refuse to start, some let the first or the last declaration win — so the practical rule is to find out which your framework does and prefer a configuration that fails at startup, since a silent winner means a handler you can read is dead code.
- Why is registering routes at startup, rather than resolving them per request, worth the extra step?Because it lets the framework precompute an index, validate templates, detect duplicates and print the full inventory once instead of doing that work on every request. It also turns a whole class of mistakes into boot-time errors rather than production `404`s, and makes the set of endpoints a thing you can list and review.
The routing table is the directory board in a building lobby: an office exists for visitors only once it has a line on the board, and a floor heading lets you write the floor once instead of on every line.
saying these in an interview costs you the question
- Thinks a handler is reachable as soon as the function exists
- Says the framework searches source files for a handler on each request
- Repeats the same prefix on every route instead of grouping
- Cannot say when the routing table is built or from what
- Assumes a route group is a separate server or port