When we talk about how the web works, we often start with HTTP methods. We discuss verbs like GET, POST, and DELETE, which act as the intent behind a request. These methods express the "what" of your interaction. They tell the server whether you want to fetch data, add new data, or remove something entirely. However, knowing what you want to do is only half the battle. You also need to tell the server exactly where you want to perform that action.
This is where routing comes into play. If HTTP methods express the intent, routing expresses the destination. It is the "where" of the request.
Imagine walking into a massive corporate archive. You have an intent, which is to retrieve a file. That is your GET method. But you cannot simply shout "Retrieve!" into the void and expect a result. You need to provide a location, such as "Row 4, Shelf B." In the world of web servers, that location is the route. The server takes your intent and your route, combines them, and maps them to a specific set of instructions called a Handler. This Handler performs the logic, talks to the database, and returns your data.
To really understand how this works, we need to look at the different ways we can construct these addresses.
The most basic form of routing is what we call a static route. These are fixed, constant paths that never change.
Consider a URL like /api/books. This path is a constant string. When you send a GET request to this specific address, the server knows exactly which Handler to trigger. It will likely go to the database, fetch a list of all available books, and send them back to you.
The interesting thing about routing is that the route itself can stay the same while the action changes. You can send a POST request to that exact same /api/books address. The server sees the same address but a different method. Because the combination is unique, it triggers a completely different set of logic. Instead of fetching books, it creates a new one. These are called static routes because they do not contain any variables. The string /api/books is set in stone.
The Flexibility of Dynamic Routes
Static routes are excellent for general lists, but they fail when we need to be specific. What if you want to fetch the details of just one specific user? You cannot write a unique static route for every single user in your database, as that would be impossible to maintain.
To solve this, we use dynamic routes. This allows us to insert variables directly into the URL path. These variables are often referred to as path parameters or route parameters.
In a server code base, this might look like /api/users/:id. The colon before the "id" tells the server that this part of the route is a placeholder. It is waiting for the client to fill it in. When a request comes in as /api/users/123, the server acts intelligently. It matches the pattern, extracts the value 123, and labels it as the "id".
This makes the URL highly readable and semantic. When you read the path, it forms a clear sentence. You are saying that you want to go to the API, look at the users, and specifically find the user with the identification of 123. The server then uses that ID to find the correct record in the database.
Adding Detail with Query Parameters
There are times when we need to send information to the server, but it does not quite fit into the hierarchy of a path parameter. This is especially true for GET requests, which do not have a "body" to carry extra data.
For example, imagine you want to search for something. You could technically try to force it into a path parameter like /api/search/some-value, but that can get messy quickly. It does not look right, and it can be hard to maintain. Instead, we use query parameters.
Query parameters live at the very end of the URL, starting after a question mark. They are key-value pairs used to provide metadata about the request. A common use case is pagination. If you have a list of a thousand books, you likely do not want to fetch them all at once. You want the first twenty.
The server might send you the first page of results along with some metadata, telling you there are five total pages. To get the next batch, you would send a request to /api/books?page=2. You are asking for the same resource, which is the books, but you are attaching a sticky note to the request that says "please give me the second page." We use these for sorting, filtering, and searching because they modify the request without changing the fundamental resource we are accessing.
Drilling Down with Nested Routes
As applications grow, the relationships between data become more complex. Routing often reflects these relationships through nesting. This is not a distinct type of technology, but rather a standard practice for keeping APIs organized and readable.
Think about the relationship between a user and their social media posts. A post belongs to a user. To express this relationship semantically, we nest the routes.
We might start with /api/users/123 to find the user. If we want that user's posts, we extend the path to /api/users/123/posts. This tells the server to find all posts specifically belonging to user 123. We can go even deeper. If we want a specific post written by that user, the route becomes /api/users/123/posts/456.
This structure tells a clear story. It says we are looking for a user (123), checking their posts, and pulling up a specific one (456). It is a logical, hierarchical way to organize data access.
Managing Change with Versioning
Software is never finished. Requirements change, and sometimes those changes break the old ways of doing things. Perhaps you were sending user data with a field called "name," but a new update requires you to split it into "first_name" and "last_name."
If you just change the API, every application currently using the old format will break. This is where route versioning becomes essential. Instead of overwriting the old logic, you create a new version of the route.
You might have /api/v1/products which returns the old data structure. When the new requirements come in, you create /api/v2/products. The server now has two active lanes. Old applications can continue driving in the V1 lane without crashing, while new applications can be built using the V2 lane.
This allows for a smooth transition. You can mark V1 as "deprecated," giving your engineering team a window of time to migrate everything to V2. Once the migration is complete, you can safely remove the old V1 route.
The Safety Net: The Catch-All Route
Finally, no matter how well you design your routing, users or clients will eventually ask for a location that does not exist. They might make a typo or try to access an old link.
If the server receives a request that does not match any of the static or dynamic routes we defined, we need a fallback plan. This is known as the catch-all route. It is usually defined by a wildcard character like an asterisk.
The server checks the request against every known route first. If nothing matches, it falls through to this final handler. Instead of the server crashing or returning a confusing error, the catch-all route allows us to send a polite, user-friendly message stating that the requested resource was not found. It ensures that even when the client gets lost, the server handles the interaction gracefully.