Static Path Routing

A parsed request has a method and a path; your server has handlers. Routing is the map between them — and starting with exact-match routes (dynamic :params next lesson) lets you get the decisions right first, because routing's hard parts aren't lookups, they're the edge semantics: trailing slashes, wrong methods, and who answers when nobody matches.

The route table

(GET,  /)           → home handler
(GET,  /about)      → about handler
(GET,  /api/users)  → list users
(POST, /api/users)  → create user

The key insight is in the table's shape: the key is (method, path) — both. GET /api/users and POST /api/users are different routes with different handlers (read vs create). A map keyed on path alone can't express REST's central convention — same resource, different verbs, different actions.

Lookup, then, is one map access… with three misses to classify, and the classification is the lesson:

The three kinds of "no match"

1. Unknown path — /nope matches nothing under any method → 404 Not Found. Easy.
2. Known path, wrong method — DELETE /about where /about has only a GET handler. The lazy answer is 404; the correct answer is 405 Method Not Allowed, plus an Allow: GET header listing what would work. The distinction carries real information ("the resource exists; your verb is wrong"), and producing it forces a better lookup structure: index by path first, then method within it — so a path-hit/method-miss is distinguishable from a path-miss. Route table design driven by status-code semantics: very HTTP.
3. HEAD — the freebie with a rule: any path with a GET handler must answer HEAD (same status and headers, no body — the response lesson's rule). Real routers do this implicitly; your spec may.

Trailing slashes and other path hygiene

Is /about/ the same route as /about? Technically distinct URLs; practically, users type both. Frameworks pick a policy — treat as identical, or 301-redirect one to the other — and your exercise's spec picks one, but the principled point stands: normalize deliberately, before lookup (case: paths are case-sensitive — /About is NOT /about; percent-decoding: %61 decodes to a before matching, a rule with security weight since /admin mustn't be reachable as /%61dmin while a naive matcher says they differ). Normalization order is the kind of thing that sounds fussy until the first bypass.

Registration-time hygiene matters too: registering the same (method, path) twice is a programmer error — real routers fail fast at startup rather than let the second handler silently shadow the first. If your spec includes duplicate registration, that's the expected behavior it wants.

Your exercise: Implement Static Router

Route registrations in, then requests; dispatch each to its handler name or the correct error, per spec. The ladder: exact hits → 404s → the 405-with-Allow case (build the path-then-method structure!) → HEAD delegation if specced → trailing-slash and case rules per spec → duplicate registration. Every "miss" case is a deliberate semantic, not an afterthought — which is the actual difference between a dictionary lookup and a router, and why this lesson exists before the pattern-matching fun of the next one.