What is Routing in Backend?

- Structured
Notes
1. Introduction to Routing
• Routing in relation to HTTP Methods:
• Builds upon the concept of HTTP methods discussed in a previous video.
• HTTP Methods define the "what" of a request - the intent or action you want to
perform (GET, POST, PUT, DELETE, etc.).
• Routing defines the "where" of a request - the resource or address where you
want to apply your intent.
• Analogy: What and Where of a Request
• HTTP Method (What): Expresses your intention to the server (fetch, add, update,
delete data).
• Route (Where): Specifies which resource you want to perform the action on or
where you want to go on the server.
• Example:
• Request: GET /api/users
• Method (What): GET - Intention to fetch data.
• Route (Where): /api/users - Resource is "users".
• Server Response: Array of users.
• Routing as Mapping:
• Routing is fundamentally the process of mapping URL parameters (route) in
combination with HTTP methods to specific server-side logic (handlers).
• This mapping allows the server to understand the client's request and execute
the appropriate code.
2. Basic Routing Demonstration (using Burp Suite & React App)
• Tools: Burp Suite (for intercepting/analyzing HTTP traffic), React App (for
demonstration).
• Demonstration of GET and POST requests to /api/books:
• GET /api/books:
• Method: GET (intent to retrieve).
• Route: /api/books (resource: books).
• Server responds with data (e.g., list of books).
• POST /api/books:
• Method: POST (intent to create).
• Route: /api/books (same resource path).
• Server creates a new book (or resource) and may return updated list of
books.
• Key Observation:
• Same route (/api/books) can be used for different actions based on the HTTP
method.
• Server uses both the HTTP method and the route to determine which handler
to execute.
• Method and Route combination acts as a unique "key" for routing logic.
3. Types of Routing
• 3.1. Static Routes
• Definition: Routes with a fixed, unchanging path string. They do not contain
variable parameters.
• Characteristics:
• Route path is constant and predictable.
• Always returns the same type of data for the same method and route.
• Example: /api/books (for GET and POST requests demonstrated earlier).
• Code Representation (Conceptual):
 R.get("/api/books", books_list_handler);
R.post("/api/books", create_book_handler);

• content_copy download
• Use code with caution.
• 3.2. Dynamic Routes (Path Parameters / Route Parameters)
• Definition: Routes that include variable parts (parameters) within the URL path.
• Purpose: To handle requests for specific items or entities within a resource
collection.
• Example: GET /api/users/123
• /api/users/ - Static part of the route.
• 123 - Dynamic part, representing the user ID (path parameter).
• Mechanism:
• Dynamic parts are typically indicated by a convention in route definition
(e.g., using a colon :).
• Server extracts the value from the dynamic segment of the URL path.
• This extracted value (parameter) is then used in the handler logic (e.g., to
fetch a specific user from a database).
• Industry Convention: Using a colon : to denote dynamic parameters in route
definitions (e.g., /api/users/:id).
• Code Representation (Conceptual):

R.get("/api/users/:id", get_user_details_handler);

• content_copy download
• Use code with caution.
• :id acts as a placeholder for any string value in that path segment.
• Semantic Readability: Dynamic routes with path parameters enhance REST API
semantic clarity, making routes more human-readable and understandable (e.g.,
/api/users/123 clearly implies fetching details for user ID 123).
• Terminology: Dynamic parts are called route parameters or path parameters.
• 3.3. Query Parameters
• Definition: Key-value pairs appended to the end of a URL after a question mark
?.
• Format: /route?key1=value1&key2=value2
• Purpose: To send additional, non-hierarchical data or metadata with a GET
request (as GET requests typically don't have a body).
• Use Cases:
• Filtering: /api/books?genre=fiction
• Sorting: /api/books?sort=title&order=asc
• Pagination: /api/books?page=2&limit=20 (Example detailed in transcript).
• Example (Pagination):
• Request 1: GET /api/books (no query parameters)
• Server returns first page of books (e.g., 20 books), along with
metadata like total, currentPage, totalPages, limit.
• Request 2: GET /api/books?page=2 (query parameter page=2)
• Client uses metadata from the first response to request the second
page of books using the pagequery parameter.
• Advantages over Path Parameters for Metadata:
• Path parameters are best for expressing hierarchical resource structure
and semantic meaning.
• Query parameters are more suitable for sending non-hierarchical,
optional metadata like filtering, sorting, pagination options, etc.
• Using path parameters for search values (e.g., /api/search/some+value)
can become semantically unclear and harder to maintain compared to
query parameters (/api/search?query=some+value).
• 3.4. Nested Routes
 • Definition: Routes that involve multiple levels of resources, creating a
hierarchical structure in the URL path.
• Purpose: To express relationships between resources and create semantically
rich API endpoints.
• Example: GET /api/users/123/posts/456
• /api/users/123 - Resource: User with ID 123.
• /posts/456 - Nested resource: Post with ID 456, related to User 123.
• Semantic Meaning:
• Expresses a nested relationship: fetching a post (resource) that belongs
to a specific user (another resource).
• Breaks down complex APIs into more manageable, semantically clear
endpoints.
• Levels of Nesting (Example Breakdown):
• /api/users - List of all users.
• /api/users/123 - Details of user with ID 123.
• /api/users/123/posts - All posts of user with ID 123.
• /api/users/123/posts/456 - Details of post with ID 456, belonging to user
123.
• Not a distinct routing type but a practice for semantic REST APIs.

Understanding Routing Types in Backend

Static Routes
Nested Routes
Routes with fixed
Routes with
paths and no
hierarchical
variables
resource levels

Query Parameters Dynamic Routes

Key-value pairs for Routes with
additional data variable
parameters in
paths

4. Route Versioning and Deprecation

• Definition: A practice of including version information in the route path (e.g., /api/v1/,
/api/v2/).
• Purpose: To manage API changes, maintain backward compatibility, and facilitate API
evolution without breaking existing clients.
• Example:
• GET /api/v1/products - Version 1 of the products API.
• GET /api/v2/products - Version 2 of the products API.
• Scenario: API response format needs to change (e.g., due to new requirements like
supporting different client apps - web vs. mobile).
• Alternatives and Advantages of Versioning:
• Option 1 (Without Versioning - Breaking Change): Modify the existing
/api/products endpoint directly.
• Problem: Breaks compatibility for existing clients relying on the old
response format.
 • Option 2 (New Route - /api/new_products): Create a completely new
endpoint for the updated API.
• Problem: Less semantically clear, harder to manage related versions.
• Option 3 (Versioning - /api/v1/products, /api/v2/products): Introduce
versioning in the route.
• Advantages:
• Clear Intention: Explicitly separates different API versions.
• Backward Compatibility: Old clients can continue using
/api/v1/products while new clients use /api/v2/products.
• Deprecation Workflow: Allows for a controlled deprecation
process:
1. Release V2 with new format.
2. Announce deprecation of V1.
3. Clients migrate to V2 over time.
4. Eventually, V1 can be removed.
• Stable API Evolution: Provides a structured and manageable way
to introduce breaking changes and evolve APIs over time.

Without Versioning
Breaks compatibility for
existing clients
How to
manage API New Route
changes? Less clear, harder to manage
versions

Versioning
Ensures backward
compatibility and clear
intention

5. Catch-All Route
• Definition: A route defined at the end of routing configurations that matches any URL
path that hasn't been matched by previous routes.
• Representation (Conceptual): /* (star wildcard) in route definition.
• Purpose: To handle requests to undefined or non-existent routes gracefully.
• Behavior:
• If a request doesn't match any specific defined route, it falls through to the
catch-all route handler.
• The handler for the catch-all route typically returns a user-friendly error message
(e.g., "Route not found", 404 Not Found status code).
• Benefits:
• Provides a better user experience than a null response or server error for invalid
routes.
• Informs the client that the requested endpoint is not supported.
• Code Representation (Conceptual):
 R.get("/*", not_found_handler); // Or R.use("/*", not_found_middleware)

• content_copy download
• Use code with caution.
• not_found_handler is executed for any unmatched GET request path.

Catch-All Route

Definition Purpose Behavior Benefits Code

A description of the Explains the function Representation
Details how the Lists advantages of
catch-all route. of the catch-all route. catch-all route using a catch-all Shows code for
handles requests. route. implementing the
catch-all route.

6. Conclusion
• Routing is essential for backend development in RESTful APIs.
• Understanding different types of routes (static, dynamic, query parameters, nested) is
crucial for designing and implementing APIs.
• Route versioning is a key practice for managing API evolution and maintaining
backward compatibility.
• Catch-all routes enhance API robustness and user experience by handling invalid
requests gracefully.
• Mastering routing concepts is fundamental for working with backend codebases,
understanding API structures, and making modifications or additions to API endpoints.