hey reader hii
today we are i mean to say u and me are going to talk about URL Parameters vs Query Strings in Express.js
yaaa yaaa its boring but let me make it intresting for u
first lets start from starting
everyone know about Tim Berners-Lee creator of URL , HTML and HTTP
he created this thing mostly to share document easily to any one
but we are going to focus on URL
why did he create URL ?
so the problem was how will we identify the document in this www or internet world
so he end up making a unique string (yes a basic developer thinking)
let decode how the first URL looks like
http://info.cern.ch/hypertext/WWW/TheProject.html
yes yes this is how it look like it is messy but everything is messy at first gradually it will get clean that what history sayy
okay okay let come back to the main topic
so in this URL
http://
this act as a protocol
tell system to use this protocol to communicate with this systeminfo.cern.ch
this is host/hypertext/WWW/TheProject.html
this is path
so if u see this carefully u can see that this kinda a looking like a file system path
why ? because developer are familiar with this strcuture
so he did not made something new he just reused a familiar structure
but till now this URL is not having the params and query
Where query strings came from ?
with development the static website get converted into a dynamic website
DB gets involve, search systems came in
dynamic content was needed, people want condition baised data
That’s where query strings appeared
so there are many parameter in an url like path , query , hash (#) ,etc
we are going to focus on path which is params and another is query
so lets start with params
so this how it look in url
/users/123/posts/456
This is not random. It follows a hierarchical structure
/resource/identifier
Where did this structure come from?
this was designed directly from file system (Unix)
/home/shivam/file.txt
so basically it means
Go inside:
users
user 123
posts
post 456
General structure pattern
Basic form:
/collection/:id
Nested form:
/collection/:id/subcollection/:subId
How Express understands this
When you write:
app.get('/users/:id', (req, res) => {
console.log(req.params);
});
Internally Express converts it to:
/users/([^/]+)
it means match after any things comes after users/
and till the next /
BTW one more thing express does not see the :id it see what is comming next after the users/ and till the next /
so :id is only showing as a wrapper code to identify it in a code so the developer can use the value in his code
how to use in express
so if first thing u have to do is to pass the name of the params so that in your code u can use it for accessing it
it look like this
/user/:id
so if u want to access it u can use
let id = req.params.id
Request:
/users/123
Extracted:
req.params = { id: "123" }
Multiple params structure
app.get('/users/:userId/posts/:postId', ...)
Request:
/users/123/posts/456
Output:
{
userId: "123",
postId: "456"
}
how lets talk about query
so the first AIM of query is to show data to user depending on condition
A query string is the part of a URL that comes after ? and is made of key=value pairs
this is how it looks like
/search?q=express&sort=latest&page=2
? starts the query string
& separates parameters
= assigns value to a key
{
q: "express",
sort: "latest",
page: "2"
}
Original purpose
“Provide additional data to the resource without changing its identity.”
That’s why
/users/123 means the user which is identity
/users?age=20 means filtered list which is instruction
if u look closely u can the query parameter is inspired by SQL COMMAND
example
SELECT * FROM users WHERE age = 20
Query string became the web version of that
/users?age=20
4. Full structure
General format
?key=value&key2=value&key3=value
Important rules
1. every one need starting point so as query so it becames ?
/users?age=20
2. there can be multiple query parameter so we use &
/users?age=20&active=true
3. keys should be unique
/users?age=20&age=30
Allowed but it can create ambiguity
one of the most important point
Everything is text
?age=20
comes as
"20"
not number
How query parsing works internally
Step by step
Split after ?
age=20&active=true
Split by &
["age=20", "active=true"]
Split by =
age becomes 20
active becomes true
Create object
{
age: "20",
active: "true"
}
In Express.js
so in params u first have to declare the params but not in this
it will directly given into the req.query so access it from there
app.get('/users', (req, res) => {
console.log(req.query);
});
Request
/users?age=20&active=true
Output
{
age: "20",
active: "true"
}
Important detail
Express uses parsers like
querystring which is basic
qs which is advanced
Advanced query formats
Arrays
/products?category=electronics&category=books
or
/products?category[]=electronics&category[]=books
Parsed
{
category: ["electronics", "books"]
}
Nested objects
/user?filter[name]=shivam&filter[age]=20
Parsed
{
filter: {
name: "shivam",
age: "20"
}
}
Boolean or numbers
?active=true
Still string
"true"
You must convert
const active = req.query.active === 'true';
Real-world use cases
Search
/search?q=nodejs
Filtering
/products?price=low&brand=apple
Pagination
/posts?page=2&limit=10
Sorting
/posts?sort=latest
Feature toggles
/dashboard?darkMode=true
14. Internal philosophy
Query params follow this principle
“Same resource, different representation”
Example
/products?sort=price
/products?sort=rating
Same resource but different view depending on how you request it
15. Final mental model
Burn this
Query means how you want the data
Example
/users/123?include=posts&limit=5
/users/123 means what resource you are targeting
?include=posts&limit=5 means how you want that data to be returned
Final closure
so if u look at everything from starting to now
you will realize that nothing in URL design is random
everything is built on simple thinking
first identify the resource clearly using path
then modify or filter the data using query
params give you the exact thing you want
query helps you control how that thing should behave
this separation is the reason why APIs today are clean predictable and scalable
if u mix them randomly then your API will work but it will not be understandable and not maintainable
and that is the difference between just making something work and actually designing it properly
so next time when you design an API do not just write routes
think what is the resource and how it should be accessed
that is where real backend engineering starts
