Query parameter vs Path parameter
Hello, can someone explain what's the difference between a query parameter and a path parameter and what are the use cases of each one pls.
Normally, I use query parameters in order to fetch a particular item from my database, like a particular user maybe. I never make use of path parameter (I think?).
Was wondering if someone can explain the differences pls.
37 Replies
just read that on stackoverflow:
Hmm, what I was used to do is, if I need to find a particular car, I would always use query params xd, is it wrong?
wrong? no
sub-optimal? maybe
I think the issue was at some point that search engines trimmed the GET parameters off to see if a page was unique or not?
and /cars/14 is just a URL, where /cars?id=14 might get lower ranking or something
I doubt it's still that simple though
yeah I see
I will force myself to only use query params when it comes to filtering
thanks !
Path parameters have an order, query parameters don't
that is a very good point
in this example, it would be better to use
/car/14, in my opinionthat's what I said, right?
cars
the difference is that
car is singular, which is the case when you pass a single id to get a single car
it's an unimportant detailoh. Eh, I see both. It's sometimes easier to just have a cars route with relevant sub-routes than to have car/:id just for details and cars/whatever for everything else
i see it as:
- 1 car:
/car/:id
- multiple cars: /cars/I know
oh, another important difference between query parameters vs path parameters is that you can pass more than 1 value and (depending on the server software) have it already formatted as an array on the server
you can do
/cars/1,2,3,4,5... but it looks clunky as hell
you can also do /cars/?id=1,2,3,4,5 or /cars/?id[]=1&id[]=2...(also, just to nip this in the bud, but stop giving a fuck what your URLs look like, it's 2025)
browsers gray out most of the URL, and people that aren't developers barely know what a URL bar is
i agree with that, but my comment isn't about looks, but about a simple mental model that may help to make things easier to remember
yeah, namespaces should be singular, always
it does help me to rationalize about it if it is singular
unless it's for an API, please care about your URLs in APIs
oh, yeah, for sure for APIs
but putting arrays in an API URL is cursed as fuck too
Yeah
That's why you care about the URL and put the array in the body
question, why when it comes to APIs, we should stick with plural namespaces?
convention
also, it's easier to understand what it returns
for example, using
car for an endpoint that returns an array of cars because you send 2 ids is a bit ... weirdyep I see
what would you expect an endpoint for
users to return?
a single user?certainly not :c
exactly
you would expect multiple users
yepp
this is why conventions exist
singular namespace, always
You can have an endpoint with a plural noun, but don't make a namespace with a plural
/products/{product id}/attributes/{attribute id} is cursedalright, noted, ty !
🤢 that is disgusting!
To go a bit further, it's convention because your company doesn't have just one
user or just one product. So the /users route returns one of many users, right?
It's the same reason why you have a users table in your database: the system has more than one user…otherwise you wouldn't need a database to keep the info, right? lol. So it's kinda mirroring the DB table names🤯
Except database tables are usually singular, because they are almost never taken as a whole but through an ORM why entities with singular names
Though it's more lax, i saw db schemas with both at the same time
That's not what I learned. DB names are plural and a single entry in that table is singluar. You get a
user from the users table
That's horribleIt is
Different cultures I guess, but db tables don't work the same as url paths anyway so it's a bit off topic
(and you should not peg your api to your db schema)