When do I use path params vs. query params in a RESTful API?

Question

I want to make my RESTful API very predictable. What is the best practice for deciding when to make a segmentation of data using the URI rather than by using query params.

It makes sense to me that system parameters that support pagination, sorting, and grouping be after the '?' But what about fields like 'status' and 'region' or other attributes that segment your collection? If those are to be query params as well, what is the rule of thumb on knowing when to use path params?

Agma

a similar question is answered here ... #3198992 – Vasculum

Answer 1

TL;DR: Best practice for RESTful API design is that path params are used to identify a specific resource or resources, while query parameters are used to sort/filter those resources.

---

Here's an example. Suppose you are implementing RESTful API endpoints for an entity called Car. You would structure your endpoints like this:

GET /cars
GET /cars/:id
POST /cars
PUT /cars/:id
DELETE /cars/:id

This way you are only using path parameters when you are specifying which resource to fetch, but this does not sort/filter the resources in any way.

Now suppose you wanted to add the capability to filter the cars by color in your GET requests. Because color is not a resource (it is a property of a resource), you could add a query parameter that does this. You would add that query parameter to your GET /cars request like this:

GET /cars?color=blue

This endpoint would be implemented so that only blue cars would be returned.

We can add more filtering parameters using the & symbol:

GET /cars?color=blue&brand=ferrari

As far as syntax is concerned, your URL names should be all lowercase. If you have an entity name that is generally two words in English, you would use a hyphen to separate the words, not camel case.

Ex. /two-words

Mew

Thank you for your answer Mike. This is a clearcut and simple methodology; worth an up vote from me. Still, oftentimes, developers opt for the 'cars/blue' approach, I'm wondering what their reasoning is for doing so... perhaps they decide to make path params for fields that are mandatory, or maybe they do it to indicate that the database is partitioned by that shard. – Agma

I am not sure what their reasoning is. Honestly, I disagree with it. I think following conventions and keeping it simple makes the most sense. By doing so, you allow the consumers of your API to better understand exactly what they need to do to access it's functionality. – Mew

what about /cars?id=1&color=blue instead of cars/1/?color=blue. you are basically filtering cars resource in each scenario – Brainwork

Wrong since car with id 1 only exist one but cars with color blue maybe many. There is the distinction between identity and filter – Geilich

My hypothesis as to why using path params is so widespread is because many developers learned from frameworks designed by people who didn't have a good grasp of REST principles (Ruby on Rails in particular.) – Canoness

Fun trivia, this-is-called-kebab-case – Andras

I’ve to generate daily and weekly reports for users. So should I use /users/user_id/reports/daily?day=2020-03-14 and /users/user_id/reports/weekly?week=13 or /users/user_id/reports?type=daily&day=2020-03-14 and /users/user_id/reports?type=weekly&week=13. These reports do not point to one particular resource, rather the report is generated based on several entries in DB table. – Curacy

what about if you have a pk with two fields and you want to get it? ie: /cars GET (List) and /cars/:id where you have id and otherId? – Bratwurst

When i want to open a car in edit mode, should i send the eidt flag as path or query parameter? Or is there any other way to communicate such edit modes to destination page. – Harold

I think path parameters are frivolous and should be done away with. It would reduce both confusion and code. It adds no practical value other than philosophy. Query parameters are sufficient for both identification and filtering. – Orbiculate

Answer 2

The fundamental way to think about this subject is as follows:

A URI is a resource identifier that uniquely identifies a specific instance of a resource TYPE. Like everything else in life, every object (which is an instance of some type), have set of attributes that are either time-invariant or temporal.

In the example above, a car is a very tangible object that has attributes like make, model and VIN - that never changes, and color, suspension etc. that may change over time. So if we encode the URI with attributes that may change over time (temporal), we may end up with multiple URIs for the same object:

GET /cars/honda/civic/coupe/{vin}/{color=red}

And years later, if the color of this very same car is changed to black:

GET /cars/honda/civic/coupe/{vin}/{color=black}

Note that the car instance itself (the object) has not changed - it's just the color that changed. Having multiple URIs pointing to the same object instance will force you to create multiple URI handlers - this is not an efficient design, and is of course not intuitive.

Therefore, the URI should only consist of parts that will never change and will continue to uniquely identify that resource throughout its lifetime. Everything that may change should be reserved for query parameters, as such:

GET /cars/honda/civic/coupe/{vin}?color={black}

Bottom line - think polymorphism.

Granados

Interesting paradigm.. Is this a commonly used design patten? Can you provide some APIs that use this in their documentation or some references that outline this strategy? – Agma

I like how you emphasized "TYPE" when you wrote "A URI is a resource identifier that uniquely identifies a specific instance of a resource TYPE". I think that's an important distinction. – Amoreta

this makes most sense. I think path variables helps parameters to be cleaner and more understandable. – Allotment

This is a very good point, and rule, in REST-API design: URI should only consist of parts that will never change and will continue to uniquely identify that resource throughout its lifetime – Lysander

Answer 3

In a REST API, you shouldn't be overly concerned by predictable URI's. The very suggestion of URI predictability alludes to a misunderstanding of RESTful architecture. It assumes that a client should be constructing URIs themselves, which they really shouldn't have to.

However, I assume that you are not creating a true REST API, but a 'REST inspired' API (such as the Google Drive one). In these cases the rule of thumb is 'path params = resource identification' and 'query params = resource sorting'. So, the question becomes, can you uniquely identify your resource WITHOUT status / region? If yes, then perhaps its a query param. If no, then its a path param.

Macroscopic

I disagree, a good API should be predictable; RESTful or otherwise. – Agma

When you say 'a good API should be predictable', do you mean the URI's should be predictable? If so, why is that important in a RESTful API? – Macroscopic

I think so. There should be rhyme and reason to how the URI is formed, rather than arbitrarily naming endpoints. When one can intuitivly write an API client without constantly referencing the documentation, you've written a good API in my opinion. – Agma

"When one can intuitivly write an API client without constantly referencing the documentation". That is where I think our understanding of REST differs... the API client should never need to 'build' a URL. They should select it from the response of the previous API call. If you take a website as an analogy... You go to facebook.com, then you select a link to the events page. You dont care whether the facebook events URL is 'predictable', as you arent typing it in. You get there via hypermedia links. The same is true of a REST api. So, make URIs meaningful to you (the server), but not th client – Macroscopic

Added note. This doesn't mean that the URIs shouldn't follow an easy to understand pattern, it just means that its not a constraint of a RESTful API. The biggest issue with this area is people assuming that a client should build the URLs themselves. They shouldnt, as that creates a coupling between client and server that shouldnt exist. (eg - the server cannot then change a URL without breaking all client applications). In a REST API, the server can change them as it pleases. – Macroscopic

+1 for using the following words: "'path params = resource identification' and 'query params = resource sorting'". This really cleared it up for me. – Beast

What if you need to validate your resource identifier? – Warford

A good REST API should have predictable URLs. Not necessarily for the sake of the client. But for the sake of the server implementors deciding how to structure their paths in a way that benefits themselves the most – Gracye

Answer 4

Segmentation is more hierarchal and "pretty" but can be limiting.

For example, if you have a url with three segments, each one passing different parameters to search for a car via make, model and color:

www.example.com/search/honda/civic/blue

This is a very pretty url and more easily remembered by the end user, but now your kind of stuck with this structure. Say you want to make it so that in the search the user could search for ALL blue cars, or ALL Honda Civics? A query parameter solves this because it give a key value pair. So you could pass:

www.example.com/search?color=blue
www.example.com/search?make=civic

Now you have a way to reference the value via it's key - either "color" or "make" in your query code.

You could get around this by possibly using more segments to create a kind of key value structure like:

www.example.com/search/make/honda/model/civic/color/blue

Hope that makes sense..

Lumper

I think this is where the concept of a resource comes in. A make and a colour are not resources. /cars is a resource. Maybe if you have different garages that sell cars then /cars/[garage]/ is a resource. Then you could search for make and colour across all cars or make and colour in a garage. – Kathie

Supplying key-value filter parameters in url paths is a bad design. That's what querystring is for. Url paths are better suited for hierarchical queries. – Kish

Answer 5

Once I designed an API which main resource was people. Usually users would request filtered people so, to prevent users to call something like /people?settlement=urban every time, I implemented /people/urban which later enabled me to easily add /people/rural. Also this allows to access the full /people list if it would be of any use later on. In short, my reasoning was to add a path to common subsets

From here:

Aliases for common queries

To make the API experience more pleasant for the average consumer, consider packaging up sets of conditions into easily accessible RESTful paths. For example, the recently closed tickets query above could be packaged up as GET /tickets/recently_closed

Brogan

add a path to common subsets makes sense! – Carolinian

Answer 6

Consider the word "path" - a way to get to a location. Path parameters should describe how to get to the location/resource that you interested in. This includes directories, IDs, files, etc.

/vehicles/cars/vehicle-id-1

Here, vehicle-id-1 is a path parameter.

Consider the word "query" - I think of it as asking a question about the path i.e. is my path blue, does my path have 100 results.

/vehicles/cars/vehicle-id-1?color=blue&limit=100

Here color=blue and limit=100 are the query parameters, which help describe what we should do once we get to our resource: filter out blue ones, and limit them by 100 results.

Impuissant

Answer 7

Generally speaking, I tend to use path parameters when there is an obvious 'hierarchy' in the resource, such as:

/region/state/42

If that single resource has a status, one could:

/region/state/42/status

However, if 'region' is not really part of the resource being exposed, it probably belongs as one of the query parameters - similar to pagination (as you mentioned).

Sapodilla

Answer 8

Example URL: /rest/{keyword}

This URL is an example for path parameters. We can get this URL data by using @PathParam.

Example URL: /rest?keyword=java&limit=10

This URL is an example for query parameters. We can get this URL data by using @Queryparam.

Urina

The question was "when" to use them not "how" to use them. Also, the @ PathParam and @ QueryParam are language specific and therefore not helpful but to a select group of people. – Vociferate