Mastering API Routing: Static, Dynamic, Query Parameters & Best Practices

What is API Routing? The Backbone of Backend Communication

Every time you open a mobile app or visit a website, your device sends a request to a server. But how does the server know exactly what you’re asking for and how to respond? The answer lies in API routing. Routing is the mechanism that maps incoming HTTP requests, defined by a method (GET, POST, etc.) and a URL path, to specific server-side logic. To fully grasp how requests flow from client to server, check out Understanding Backend Architecture: How Requests Travel and Why Backends Matter.

A well-designed route structure acts like a table of contents for your API. It allows developers to organize endpoints logically, making the API intuitive to use and easy to maintain. Without proper routing, even a simple server would quickly become a tangled mess of conditional statements.

Static vs. Dynamic Routes

Routes generally fall into two categories:

Static Routes: These have a fixed path and return the same resource for every request. For example, /api/users/profile always points to the currently authenticated user's profile. Static routes are simple, predictable, and easy to cache.
Dynamic Routes: These contain parameters that change based on the request. For instance, /api/users/:id uses a dynamic segment (:id) to fetch a specific user. This pattern is essential for CRUD (Create, Read, Update, Delete) operations.

Understanding when to use dynamic routes is crucial. For a deeper look at building scalable backend structures, explore Master Backend Engineering: First Principles for Faster Onboarding in Any Language. Dynamic routing allows you to build generic handlers that adapt to different inputs, reducing code duplication.

Path Parameters vs. Query Parameters

Both path parameters and query parameters allow you to pass data to an endpoint, but they serve different purposes:

Path Parameters: Part of the URL path itself. They identify a specific resource (e.g., /orders/123 where 123 is the order ID). Use them for mandatory and hierarchical data.
Query Parameters: Appear after a ? in the URL, formatted as key=value pairs (e.g., /orders?status=pending&page=2). Use them for optional filters, sorting, pagination, or search queries.

Best Practice Examples

| Purpose | Path Parameter | Query Parameter | |-------------|--------------------|---------------------| | Fetch a specific product | /products/42 | ❌ Not recommended | | Filter products by category | ❌ Not recommended | /products?category=electronics | | Update a user’s email | /users/789/email | ❌ Not recommended | | Search with keywords | ❌ Not recommended | /search?q=nodejs&limit=10 |

Rule of Thumb: If the parameter is required to identify a unique resource, use a path parameter. If it modifies how the response is generated or filtered, use a query parameter. For more on building robust endpoints, refer to Comprehensive Guide to HTTP Protocol and Express.js for Web Developers.

HTTP Methods and Their Role in Routing

Routing is deeply tied to HTTP methods (also called verbs). The same URL can behave differently depending on the method used:

GET /users → List all users
POST /users → Create a new user
GET /users/:id → Fetch a single user
PUT /users/:id → Replace a user
PATCH /users/:id → Partially update a user
DELETE /users/:id → Remove a user

This pattern, often called RESTful routing, makes APIs predictable. A developer who knows the conventions can guess the correct endpoints without reading extensive documentation. To master these conventions, dive into HTTP Protocol Fundamentals: Statelessness, Methods, CORS, Caching, and Status Codes for Backend Developers.

Nested Routes: Organizing Hierarchical Resources

Sometimes resources are naturally nested. For example, a blog might have posts that belong to authors. You can express this with nested routes:

/authors/:id/posts → List all posts by a specific author
/authors/:id/posts/:postId → Fetch a specific post by that author

When to nest: Only when the child resource makes no sense without the parent. If you frequently need to access a resource directly (e.g., /posts/42), avoid deep nesting. Over-nesting can make URLs long and coupling tight.

Route Versioning: Future-Proofing Your API

APIs evolve. To avoid breaking existing clients, always version your API from day one. Common strategies include:

URI versioning: /v1/users, /v2/users
Header versioning: Custom header like Accept: application/vnd.api.v1+json
Parameter versioning: /users?v=1 (least recommended)

The simplest and most transparent approach for most projects is URI versioning. For example, Comprehensive Introduction to API Testing Fundamentals and Tools often relies on versioned endpoints to ensure backward compatibility during testing.

Catch-All Routes and Error Handling

No routing system is complete without a catch-all. A catch-all route matches any URL that hasn’t been matched by previous routes. This is essential for:

Returning a custom 404 page
Logging invalid requests
Handling legacy or deprecated paths

In Express.js, a catch-all looks like:

app.use((req, res) => {
  res.status(404).json({ error: 'Route not found' });
});

Always place your catch-all after all other route definitions.

Best Practices Summary

Be Consistent: Follow a naming convention (e.g., plural nouns for resources: /users, /orders).
Use Nouns, Not Verbs: /getUsers is redundant; GET /users already implies retrieval.
Limit Nesting: Max 2–3 levels deep.
Document Immediately: Use tools like Swagger/OpenAPI as you build.
Test Your Routes: Automated tests prevent regressions when you add new features.

By mastering these routing concepts, you’ll build APIs that are intuitive, scalable, and easy for other developers (and your future self) to understand. Remember, great routing is invisible, it just works, guiding every request to its perfect destination.

next we have is routing in the previous video we talked about different HTTP methods and how they are important in

the HTTP semantic so in a way all these HTTP methods they describe your intent which we already talked about and you

can say these HTTP methods they express the what of a request your intent your action what do

you want to do on that particular resource or what do you want to tell your server that your intention is

whether you want to fetch some data or add some data or update some data or delete some data and the role of routing

is it expresses the where of a request where do you want to send your intention where or which resource you want to

perform your action or your intent on you need to tell the server where do you want to go for example you have a

request and the method is get right your intention is fetching or getting some data from the server

and your route path or the URL path is slash users and the server sends you an array

of users okay so what you're saying is I want to fetch some data you want to

fetch some data your action is fetching and from where or what kind of data right this is the resource this is the

route whatever you want to call it and the combination of these two your intention your action and your route the

URL parameters the address the server takes this and this and Maps it to a particular Handler or a set of

instructions and it performs all the business Logic the database operations and whatever is needed and returns you

the data and to summarize it you can say that routing is basically mapping URL parameters to a server side logic and

and that's all there is to it and here we have our familiar BB Suite interface and we have a react app which we will

use to demonstrate some of these routing Concepts so I'll just go ahead and fire some apis and then we can jump in and do

some analysis so the first request was a get request and if you look at the request and response this part we are

already familiar with this is the HTTP method this is our intent or the action we want to perform which is get or

patching now the this part this is what we call the route right the address of our request where do you want to go in

the server which is in this case / API SL books books is called a resource and we'll learn more about resource when we

study about rest API concepts for now we can just assume this is a route right and this is a route so this is our

action this is the address you want to go to in the server and when we send this request and the request goes

through the server responds with this data right whatever the responses it does not matter and for the sake of this

demo we are just sending some fillers but typically this is what happens you send a request the server does some kind

of authentication if it's there then it sends the data and then in the next request which is a post request here the

intention is post the HTTP method is post the route is still the same/ API SL books the request goes through it

creates another book or whatever the resources and it returns all the resources again in the response right so

if you notice here in the previous request and in this request this route part is the same so what happened is in

the previous request the request was a get method and the route was SL API SL books and in this request it's a post

method right and the route is still the same/ API Das books so what happens in the server is these two things the

method and the route these two things are kind of a key which map to a particular Handler in the server right

the server first checks what the method is then it checks the route and it concatenates these two and forms a

unique routing logic right this is a unique path and this is another unique path these two will never Clash right

these methods they differentiate between the two routes and now that we know what what basic routing is we can jump into

different types of routing right and the first two examples that we discussed the/ API SL books for get and post these

kind of routing or routes are called Static routes right and why are they call static routes for obvious reasons

because they don't have any variable parameters inside the route and what do I mean by variable for example this part

SL aa/ books this will stay consistent this is a constant right we don't have to think about a dynamic parameter

inside this route this is constant we are always going to use this string / API / books whenever we make the request

nothing changes in that and it is always going to return this kind of response that's why it's called a static route

it's a constant or it's a particular string which never changes and it always returns the same kind of data so in that

case what is a dynamic route so let's fire these two requests now and if we look at the first one so here

if you see the method is get and the route is/ API SL users sl12 3 and in this case this is supposed to express

the ID of the user the application of this API endpoint is we can fetch details of a one particular user using

the ID of the user inside the route parameter and when we make this request the server can extract this particular

ID from the route path and it can do whatever operation it wants to do like fetching the user from the database and

returning the details of the user in this case we just the server is just fetching the user ID and returning it in

the response to express that it got the user ID from the route since in this video we are not going to get too much

into the code and we just want to understand the concepts behind it but just to give you an idea this is what

the the route matching part in the server looks like the server is basically saying let's say the Handler

is called route or let's say it's called R right R do get and in the matching part it is

saying it's a string slash API SL users slash colon ID this part matches the method in the

server and this part this part matches the route so the server is saying if any request with the method get

and with the route slash API SL users and in the next part any kind of string right this Fallen ID it basically means

any kind of string that comes in this format routed to this Handler whatever Handler is waiting to respond to that

kind of route right so the thing to remember is uh this convention you'll find in any kind of servers it does not

matter it's Java or python or nodejs or goang rust it does not matter this just a convention find this is what I've seen

the industrywide practices mostly colon which says it's a dynamic parameter that the user is going to send in place of ID

the use of this is when the request comes in our case request was / API SL users and /1 23 the request got routed

to this part it matched with the get right we we were sending a get request and in the next part it matched the

first / API then the next one/ users and it's a string right it looks like a number but in route parameters or in

route paths whatever uh number special characters everything is converted into a string so this thing this gets

inserted into this slot this Dynamic parameter slot which we are calling as ID if you read it it's clearly readable

right you can read it like you're saying patch me some data because it's get and where is that data that is in/ API SL

user and whose data that is it is with of the user with ID 1 2 3 right it's clearly

readable that's the whole idea of rest apis because it it it provides a human readable construct to routing this is

called a dynamic route and the terminology that we use is this part is called a route parameter or path

parameter that is something to remember we have like two different types of parameters that's a little confusing one

is these kinds of parameters these kinds of dynamic parameters are called path parameters because they go right after

the forward slash right it is part of the route that's why they are called path parameters or route parameters and

the next one we have query param so for this we can just type out something let's

say some value and let's hit this API and we if we look into this API this is what it looks like this is the method

and this is the route right this whole part is the route basically the route is/ API SL

search question mark query equals to sum plus

value and now I realize this is more readable here than here but anyway we'll make do so this part we understand right

this is the route / API SL search this is the address that we want to go into the

this is the part that server uses to match including the method and this route this is the part the server uses

to match it to some Handler and it performs the logic and returns some data which is not important the thing to

focus here is the query part here the question mark and the key and the value this is called query parameter that's

the terminology and next is the application why do we use it because in post requests or in put requests we have

the body of the request right we get to use the body and we can use the body to send some kind of data send parameters

that we want to attach into the request we have some kind of container to send some user defined values into the server

but in case of get request in rest API get requests don't have a body you want to send some value in the get request so

let's say you can say that we can send those values in the path parameters right but path parameters serve a

particular purpose right they serve as a semantic expression right in the previous request that we saw we were

saying SL API SL users SL1 23 and the semantic meaning here is we want to fetch the details of a user whose ID is

1 2 that is the semantic expression in the path parameter but if we want to say we want to call this API which is/ API /

search and we want to say the search value is some random value uh that the user has typed into the input box how do

you want to send it let's suppose we want to send it in the path parameter what will it look like SL API SL search

and Slash the value in this case it will be some value some value technically technically

it's possible you can do this but it's it's very hard to maintain and it it it defeats the whole purpose of rest API

right providing semantic Expressions to AP end points it defeats the whole purpose that's why we have this concept

called query parameters in query parameters we can send a set of key value pairs in a request typically we

use it with get request because we don't have a body to send data in so in get request we get these thing called query

parameters which are key value pairs that we can send to the server to let to send some kind of metadata about the

request for example let's say it's a request about fetching paginated data you want to petch a list of books which

are paginated we have not gotten into pagination yet but I'm pretty sure you must have encountered it at some point

they basically look like this so let's say it's a endpoint which fetches a list of books in paged format so it looks

something like this SL API SL books and when you hit it the server returns an object or a Json and inside data you

have whatever the a list of an array of books and it returns some a set of metadata about the response right and it

looks something like this like total current page and total

Pages things like this it depends on the implementation but something like this so the purpose of this is and you also

have a limit here purpose of this is the server will paginate the data the response and it will send a chunk of

data let's say the limit is 20 there's some kind of default limit so what the server will do is it will send 20 books

from the start and it will let you know how many books are there in total let's say 100 books and what is the current

page which is the page one and what are the total pages and if you divide 100 by 20 it will be like five pages right

these are all the kinds of values you'll receive from the server and the client can use these parameters use this

response metadata to make the subsequent requests accordingly according to the client's needs how how can it fetch the

next page in the next page it can do/ API SL books and in the query parameter it can do page equals to two right

because by default the server send the page one we did not have to send any request any query parameter for the

value of page or limit but in the second request we want do we want to tell the server that we want the response for

page two so in a get request we can send that information using query parameters this is one application usually API send

different kinds of parameters in the query for example you want to filter by some user defin parameter you want to

sort it what is the order you want to sort in whether it is ascending or descending all these kinds of

information will go inside query parameters in in the form of key value so that is basically the uses and the

definition of quy parameters and this is what the API typically looks like next we have is nested route this is not

really a type of routing it's just a practice that you will see everywhere because in rest apis for a semantic

expression we often have to resort to nesting right nesting different types of resources and the nested route is

typically the result of that and if we hit this API and want to see what it looks like this is what the request and

response looks like so what it says is is is the get request and this is the route uh we can say this is the static

part of the route and this is one Dynamic route parameter or path parameter and this is the second Dynamic

path parameter and the application of this is and why do we do this because again to express the semantic meaning so

what we are saying here is we want to do a get operation on

this route right let's say/ API / users with the user whose ID is 1 2 3 you want to fetch the details of this

user so semantically the first part expresses that we are fetching information or data which is related to

this user and the second part says we are again fetching the posts of that user and to go one level deep again you

are fetching a a particular post which is the post with ID 456 we can stop at different phases here okay let's see so

the first part the static part is/ API SL users this is a static part and this in itself is one route which we saw

earlier it it it returns a result right if you do/ API SL users it will return list of all users because that's the

Handler of that match is doing right if we go one level deep again/ API SL users SL1 23 and this is a unique route in

itself because we added a dynamic parameter and in the server s side it will see the get method and it will

match with a different Handler right and that Handler will return the information of this user whose ID is 1 12 3 so this

is one level of nesting we can go further which is/ API SL users SL SL1 23 and/

posts and now at this point what the Ser will seees it's a get method and we are it will match with a Handler which

returns all posts of a particular user because we stopped here right and this expresses a different meaning

altogether we are fetching the posts of a user with ID 1 2 3 all the users posts right and and in this demo what we are

doing is SL API SL users SL1 23 SL posts SL 456 and what this is saying we want to

fetch data of user with ID 1 123 what do we want to fetch we want to fetch the posts and not all post we want

to fetch a particular post with the ID 456 so for obvious reasons this is called a nested route right because we

Nest different types of information in different levels to express different semantic meanings and it results in

different kinds of responses all right that's all there is to it in nested routing it's pretty convenient and you

will see it getting used pretty much everywhere if the API is even has a medium level of complexity next up we

have an interesting concept called route versioning and deprecation so let's just fire these two apis and we'll jump into

the concept of that okay so if you look into this so this looks pretty much like our

earlier request except it has this keyword which is V1 it it says API slv1 SL products and if you look at the

second request it says V2 right so this is called route versioning it is a very common practice in API endpoints uh

servers which has a rest API uh interface and the the use of this is if we look at these two requests and

responses for that we'll understand why do we use versioning in servers right in API endpoints if you look at the

response of this we are saying / API slv1 products and this is what the response looks like it has field data

and and it has an array and each array has an object Json with ID name price ID name price right and in the second

request which is the V2 request we have again data and we have ID title price right in the first one we had ID name

price in the second one we have ID title price and now it is a pretty trivial example usually the use of versioning is

let's say you have an API endpoint and you are returning data in a particular format right and later on new

requirements came in let's say you were earlier serving a web app and future in the future you are serving a react

native app right an Android app or a flutter app for that entity or that device you had to change the response of

your data so your first option is changing the whole route right changing the whole route matching part so let's

say you can say/ API SL new products right or what you can do is you can add that to your versioning you can say in

the version one of our API we were serving responses in this format and new requirements came in and in version two

we are serving in this format one thing it expresses your intention very clearly you have the version one of response

your version one of response and you have version 2f response the second part is you did not have to change your whole

route you did not have to do/ API SL new products using this versioning concept you can even eventually deprecate V1 you

can let's say uh send a notice to your front end Engineers that after the V2 is released V1 is deprecated so in the next

release all the engineers can eventually migrate to V2 so they have this window a particular window where they have the

opportunity to migrate the request endpoints to the V2 format and eventually you will completely get rid

of V1 and you'll make the V2 to V1 right so you have a very stable and complete workflow to add new structure to your

API endpoints add breaking changes to your API endpoints using this workflow and your engineers your client have

window where they have the opportunity to migrate into the new structure that's the use of route versioning and

deprecation in the end we have something called catch all route so if we hit this and if we look at the request and

in response so we what we are doing here is we are sending requests to a route which

the server does not serve for right we are doing SL a/ V3 SL products at this point the server does not serve

responses for this route right it does not have an Handler it does not cater to requests coming into this endpoint so

typically what the server will do is in the end after serving all the different routes and all the methods uh associated

with those route in the end it will do is slash star whatever request after going

through all the previous route matching algorithms whatever request reaches here this part it will be mapped to a Handler

and that Handler will send a userfriendly message that this route which you are requesting this route does

not exist right this route are not found so instead of just sending a null response which is the default Behavior

if you don't do a catch all handling we are just sending a userfriendly message to let the client know that we don't

cater to this endpoint that's all catch all route is about and with that we have covered pretty much all the concepts

that one needs to know before diving deep into different kinds of routing and all the components of routing like query

parameters path parameters and all the nested Dynamic parameters and that's all pretty much you need to know to get into

a backend code base and and understand the routing parts and make changes to it and add new things

Keep this summary

Save it to LunaNotes and it becomes a real note in your library — editable, searchable, and ready to turn into flashcards or a diagram. Free to start.

Save to LunaNotes

Or summarise for another video.

This summary and transcript were automatically generated using AI with the Free YouTube Transcript Summary Tool by LunaNotes.

Related summaries

Comprehensive Guide to HTTP Protocol and Express.js for Web Developers

Explore the fundamentals of the HTTP protocol—including request methods, status codes, headers, and the stateless nature of HTTP. Learn practical usage of HTTP concepts through Node.js and Express.js examples, and discover how tools like Postman and browser DevTools help in testing and debugging APIs effectively.

Master Backend Engineering: First Principles for Faster Onboarding in Any Language

Learn how to apply first principles to backend development, enabling you to quickly navigate unfamiliar codebases and languages. This guide covers key strategies for senior-level pattern recognition, faster onboarding, and choosing the right tools, making you a more versatile and employable engineer.

Comprehensive Introduction to API Testing Fundamentals and Tools

This session covers the basics of API testing, including client-server architecture, types of APIs, and key testing methods. Learn how APIs function as intermediaries between front-end and back-end systems, the importance of API testing, and the tools like Postman and Rest Assured used for manual and automated testing.

Modern Next.js 2025 Tutorial: Complete Full-Stack Framework Overview

This comprehensive overview covers the latest Next.js features including Server Components, Server Actions, AI coding agent support, partial pre-rendering (PPR), and the new proxy system. Perfect for beginners and experienced developers looking to understand Next.js fundamentals like data fetching, caching with `use cache`, routing, authentication, and deployment options.

HTTP Protocol Fundamentals: Statelessness, Methods, CORS, Caching, and Status Codes for Backend Developers

This comprehensive guide explains core HTTP concepts every backend developer needs to know, covering stateless architecture, request/response headers, methods, status codes, CORS flow, caching strategies, content negotiation, and large data transfer. You'll learn why HTTP is stateless, how browsers handle cross-origin requests with preflight checks, and practical ways to optimize performance using caching and compression.

Start taking better notes today with LunaNotes

Start for free