6. What is Routing in Backend? How Requests Find Their Way Home
6. What is Routing in Backend? How Requests Find Their Way Home
Video: YouTube
Caption basis: English auto-generated captions. This note summarizes only what the captions support.
What this video teaches
Routing maps the where of a request—the URL/path—to server-side handling, while the HTTP method expresses the what or intended action. The video demonstrates how the method plus path selects a handler.
Key lessons from the video
- A route match uses both method and path, so
GET /api/booksandPOST /api/bookscan map to different handlers. - Static routes have no variable path segments; dynamic routes use path/route parameters such as
:id. - Path parameters identify a resource in a readable route, while query parameters carry key/value request options such as page, limit, filter, or sort.
- Nested routes can express relationships, for example a particular user's post.
- Versioned routes let a service introduce breaking response changes while giving clients time to migrate and deprecate an old version.
- A catch-all route gives a deliberate, user-friendly response when no known route matches.
Detailed teaching notes from the video
Routing joins intent with destination
The video makes a useful separation:
- The HTTP method says what the client intends to do.
- The route/path says where that intent applies.
The server uses both to select a handler. GET /api/books and POST /api/books are different operations even though the path is identical. The combination is the key that maps a request to server-side instructions.
Static and dynamic routes solve different address problems
A static route is fixed: /api/books always has the same literal segments. A dynamic route reserves part of the path for a value, such as /api/users/:id. When a request arrives as /api/users/123, the router matches the literal pieces and captures 123 as the id parameter for the handler.
The video emphasizes that everything in a URL path arrives as text. A route parameter that looks numeric still needs validation and conversion before it becomes an application ID. Do not assume :id is valid simply because the router matched it.
Path parameters identify; query parameters modify a retrieval
The lesson separates two kinds of values:
/api/users/123 → path parameter identifies the user
/api/books?page=2&limit=20 → query parameters shape the list retrieval
Use path segments when the value is part of the resource's identity/relationship. Use query parameters for optional dimensions: paging, filtering, sorting, search, or a representation preference. The video explains that GET normally has no request body in REST-style use, so query parameters are the usual way to carry list options.
Nested routes express relationships, but depth is a design cost
The video demonstrates /api/users/123/posts/456: it says “a particular post belonging to this particular user.” This can be clear when the parent relationship is genuinely important. However, nesting makes the contract stricter. A handler must decide whether the parent is only contextual or whether it must be verified as the owner of the child.
In production, do not use a deeply nested URL merely because it can be written. Keep nesting when it communicates an access/ownership boundary; otherwise a direct /posts/456 plus authorization may be simpler.
Versioning gives clients a migration window
The video shows /api/v1/products and /api/v2/products returning differently shaped data. Versioning lets the server introduce a breaking contract change without instantly breaking existing clients. The important part is not the v1 string; it is the migration plan: document the new behavior, give consumers time to move, observe traffic to the old version, and remove it deliberately.
A catch-all route is part of API usability
When no route matches, a catch-all handler returns a controlled not-found response instead of a mysterious empty/undefined result. This is a small feature with a large debugging benefit: it helps API clients distinguish a route mismatch from an application bug or an authorization failure.
Timestamp map
- 00:00 — Routing as the “where” paired with an HTTP method as the “what.”
- 03:00 — Static routes and dynamic/path parameters.
- 09:00 — Query parameters, pagination, filtering, and sorting.
- 15:00 — Nested routes and resource relationships.
- 18:00 — URL versioning and deprecation.
- 21:00 — Catch-all/not-found handling.
Check yourself
For GET /api/users/123/posts?page=2, can you say which part identifies the resource relationship and which part controls the result set?
Study prompt from this lesson
Design routes for a task app without writing code. For each route, state its resource, method, path parameters, optional query parameters, authorization rule, success response, and a 404/403 distinction. Then turn the table into OpenAPI before building handlers.