We already know how to read a request and build a correct response. What is missing is the decision in between: which piece of code serves each request. That is routing.

A router is nothing more than a function that, given a (method, path) pair, finds the handler it belongs to. It sounds trivial, and the first attempt fits in ten lines of if/else. The problem is that this first attempt falls apart as soon as the first path with an identifier inside it appears, /events/evt-001, and from then on every new route makes the mess worse. In this lesson we build a real router: a route table, /events/:id-style patterns compiled into regular expressions, parameter extraction, 404 when the route does not exist, 405 with an Allow header when it exists but under another method, and a central try/catch that maps our error.appCode values to HTTP statuses using the table from the previous lesson. It is the first appearance of the idea of a centralized error handler, which Express will formalize in lesson 06-07.

1. What routing is exactly
2. The naive attempt: if/else over req.url
3. Where it breaks: routes with parameters
4. The route table
5. compilePattern: from /events/:id to a regular expression
6. Normalizing the path before matching it
7. Matching, extracting parameters and responding 404 or 405
8. Asynchronous dispatch and centralized error handling
9. The routes of the Escena Viva API
10. Why we will use Express from Module 6 onwards

Routing is matching a (method, path) pair to a handler. Nothing more. All the complexity of real routers —Express, Fastify, Koa— comes from three added requirements, and a router that solves them is already genuinely useful:

• Patterns have variable parts. /events/evt-001 and /events/evt-002 must go to the same handler, which needs to know which of the two it got.
• The method is part of the route's identity. GET /orders (list) and POST /orders (create) are different things sharing a path.
• Failures have to be told apart. "That route does not exist" (404) is not the same as "that route exists, but not with that method" (405).

This is how everybody starts, and for two routes it is perfectly fine:

Notice the returns: they are the discipline from the previous lesson, the one that prevents ERR_HTTP_HEADERS_SENT. And this code already has a silent bug: it compares against req.url instead of the pathname. GET /events?venue=Sala%20B%C3%B3veda does not match '/events', because the string includes the query. The result is a baffling 404 that only shows up when somebody adds a filter. The fix is the one from 04-02: parse with new URL and compare against url.pathname.

Now add GET /events/evt-001. Since the identifier is variable, equality comparison no longer works, and manual slicing appears:

With four routes it is bearable. With twenty it is unreadable, and along the way you will hit very concrete problems:

The solution is not writing better ifs: it is separating the declaration of the routes from the logic that matches them. You declare a table; a generic engine walks it.

A route is an object with three fields —{ method: 'GET', pattern: '/events/:id', handler: getEvent }— and the router is a list of them plus two operations: register and dispatch.

With that shape, adding a route means adding a row, and the engine never changes. This is a request's full journey, and everything that follows is filling in those boxes:

We need to turn the string '/events/:id' into something that can say whether '/events/evt-001' matches and, on top of that, extract evt-001. The natural tool is a regular expression with capture groups. It is built in three steps:

The resulting expression is worth reading slowly. For '/events/:id/sessions' we get:

Piece by piece:

The two critical details are [^/]+ and the anchors. [^/]+ instead of .+: with .+, the pattern /events/:id would match /events/evt-001/sessions and id would be 'evt-001/sessions', trampling another route. And without ^ and $, /events would match inside /admin/events/delete, which besides being a functional bug is a security hole.

+ instead of * matters too: with *, /events/ (trailing slash, no identifier) would match with id being an empty string, and you would end up looking for event ''.

With the pattern compiled, matching a path and extracting the parameters is straightforward:

Returning null rather than {} is deliberate: a pattern with no parameters that matches returns an empty object, which is different from "no match". Confusing the two with an if (!params) would be a bug, because {} is truthy but null is not.

The same page can be requested in several ways, and they must all lead to the same place:

About capitals, the spec is clear and counterintuitive: the domain is case-insensitive, the path is not. /Events and /events are different resources. Lowercasing the path "for convenience" seems friendly until a legitimate identifier carries capitals (EV-2026-000123) and you destroy it. If you want to be tolerant, do it with a 301 redirect to the canonical form, not by silently matching: for the same reason the trailing slash is normalized instead of registering two routes, because one piece of content living at two addresses confuses caches and hurts you in search engines.

We now have all the pieces. This is the complete src/server/router.js:

The 405 is the part almost everyone skips, and the spec is explicit: a 405 response must include the Allow header with the accepted methods. Seeing it work:

A client that gets a 404 assumes it used the wrong URL and gives up. One that gets a 405 with Allow: GET, HEAD knows exactly what to do. It is the difference between an API you can explore and one you have to guess.

About ordering and specificity: our router walks the table and the first match wins, so the most specific routes go first. With /events/:id and /events/featured registered in that order, /events/featured would fall into the first one with id = 'featured'. Serious routers sort by specificity; ours delegates that responsibility to you, which is why you should always register literals before patterns with parameters.

The handlers are async, because nearly all of them read the catalog. That means any of them can throw, and we do not want to repeat a try/catch in each one. We move it up just once into the dispatcher:

This is a before-and-after moment in the server's architecture:

• Handlers stop handling HTTP errors. If the event does not exist, they throw EVENT_NOT_FOUND and forget about it. The translation to 404 is done by bodyForError, in a single place.
• The domain still knows nothing about HTTP. Event.reserve throws INSUFFICIENT_CAPACITY just as it did when the Module 1 CLI called it.
• Nothing is lost. An error with no known translation becomes a 500 and is logged to stderr, which is exactly what we want in order to find out about it.
• res.headersSent decides the last resort. If the response was already under way (halfway through serving a file, for instance), the honest thing is to destroy the connection: the client will detect the truncated response.

This pattern —a wrapper that catches and translates— is exactly what Express calls an error handler, with its four-argument signature (err, req, res, next). We will see it in lesson 06-07 and you will recognize the idea instantly, because you have just written it.

With the engine ready, declaring the API is almost like reading a list:

And the server from lesson 04-01 collapses into a single line: http.createServer(createHttpHandler(registerRoutes(createRouter()))). A full check of the API:

Our router works, it is short and you understand every line of it. And even so, in a real project almost nobody would write this. It is worth being honest about what it does not have:

So why did we do this? Because Express is not magic, it is this very table with more years on it. When in lesson 06-03 you write app.get('/events/:id', handler), you will know that inside there is a pattern compiled into a regular expression, a req.params object coming out of the capture groups and a dispatcher walking a list. And when something does not work —a route that is never reached, an unexpected 404, an error handler that never fires—, you will not be debugging a black box.

• Matching against req.url instead of url.pathname. Any query parameter breaks the match and produces an inexplicable 404.
• Using .+ instead of [^/]+ for the parameters. The pattern swallows whole segments and tramples other routes.
• Forgetting the ^ and $ anchors. /events would match inside /admin/events/delete.
• Registering /events/:id before /events/featured. The first match wins, and the literal route becomes unreachable.
• Returning 404 when 405 is what fits. And if you return 405, the Allow header is mandatory.
• Lowercasing the path. It destroys legitimate identifiers such as EV-2026-000123. If you want tolerance, redirect with a 301.
• Putting a try/catch in every handler. Repetition, inconsistency and swallowed errors. One central one is enough.
• Tip: expose router.routes and add a GET /routes route in development that lists them. It is the cheapest documentation there is.

Write src/lab/test-patterns.js that, without starting any server, checks these cases and prints a pattern | path | matches | params table: /events against /events and /events/evt-001; /events/:id against /events/evt-001, /events/evt-001/sessions and /events/; /events/:id/sessions/:sessionId against /events/evt-002/sessions/ses-002-1; and /reports/2026.json against /reports/2026Xjson. Explain the last case.

Register DELETE /events/:id in the router with a handler that throws INVALID_STATE if the event has tickets sold. Check with curl -i that: DELETE /events/evt-001 gives 409, DELETE /events/evt-999 gives 404, PUT /events/evt-001 gives 405 with Allow: DELETE, GET, HEAD, and DELETE /events gives 405 with Allow: GET, HEAD.

Add a per-route counter to the router (using route.pattern as the key) with the number of requests and the total time in milliseconds, plus a GET /metrics route that returns it sorted by average time, descending. Measure the effect: which route is the slowest and why?

Solution 1. The interesting case is the last one: /reports/2026.json against /reports/2026Xjson does not match, because step 1 of compilePattern escaped the dot and turned it into a literal. Without that escaping, . would match any character and the X would sneak through.

Solution 2. The handler only deals with the domain; the statuses are set by the table from 04-02:

evt-001 has 276 tickets sold, so it returns 409. Note that the PUT gives a 405 with DELETE and GET in Allow: the router walked the whole table accumulating the methods of every entry whose pattern matched, which is why Allow comes out complete.

Solution 3. The counter wraps around the handler call, inside dispatch:

The finally is essential: without it, a request that throws would not be counted and the averages would lie precisely in the cases that matter most. The slowest route will be /events/:id/sessions, because getEventById walks the catalog after reading it; with the memoization from lesson 03-01, the first request costs a disk read and the following ones almost nothing. That jump between the first measurement and the rest shows up perfectly in /metrics.

Escena Viva now has a navigable API. You have seen that routing is matching (method, path) to a handler, that the if/else over req.url is wrong from the very first moment —it compares the query along with the path— and that it becomes untenable as soon as parameters appear: magic indexes, length conditions and a fragile ordering nobody dares to touch.

The alternative is src/server/router.js: a table of { method, pattern, handler } and a generic engine. compilePattern turns /events/:id into /^\/events\/([^\/]+)$/, and now you know exactly why each piece is the way it is: the ^ and $ anchors so the whole path has to match, [^/]+ so a parameter does not eat a neighboring segment, + instead of * to reject the empty value, and the prior escaping so a dot in the pattern is a real dot. match extracts the capture groups and decodes them per segment, normalizePath collapses slashes and strips the trailing one, and capitals are respected because paths are case-sensitive. Failures too: 404 if nothing matches, and 405 with the mandatory Allow header if the route exists under another method.

And above all, you have your first centralized error handler: a single catch in the dispatcher that calls bodyForError, maps EVENT_NOT_FOUND to 404 and INVALID_STATE to 409, logs the 500s without leaking them and checks res.headersSent before attempting to respond. The handlers in src/server/api-routes.js have come out clean: they do their job and throw with error.appCode. That idea is the one Express formalizes in 06-07, and you will recognize it instantly because you have just written it.

With GET /events, GET /events/:id, GET /events/:id/sessions and GET /health running, the API returns JSON. But a ticketing platform also has to show a page. In the next lesson, Serving Static Files, we will build Escena Viva's mini front-end from this same server: we will map the URL to a disk path protected with resolveWithin —and you will see live how GET /../../data/events.json walks off with your data without that defense—, we will send the files with createReadStream and pipeline instead of readFile, and we will learn to respond 304 Not Modified with ETag so the second visit downloads nothing.