Return to Answer

Query parameters are a good semantic fit for this, and plenty of APIs are implemented this way, see for example OpenStack API. Using query parameters where each filter maps directly to a single attribute makes it easy to combine filters for either representing a logical intersection between two result sets (AND) or a logical union (OR), but not both at the same time. E.g. the following request can be interpreted two ways:

It may be necessary when querying for resources that you may need more complex logic to determine which results are formed. In this case you need to be a little smarter in how you set up the query parameters for the filters and would probably need some form of query language to be implemented. The actual parameters in the URL would not map to attributes of your resources, but the values instead contain references to the attributes, along with other assorted things that languages have such as operators like '>', '<' and keywords like AND and OR. See for example JIRA JQL:

Query parameters are a good semantic fit for this, and plenty of APIs are implemented this way, see for example OpenStack API. Using query parameters where each filter maps a single value directly to a single attribute makes it easy to combine filters for either representing a logical intersection between two result sets (AND) or a logical union (OR), but not both at the same time. E.g. the following request can be interpreted two ways:

It may be necessary when querying for resources that you need more complex logic to determine which results are formed. In this case you need to be a little smarter in how you set up the query parameters for the filters and would probably need some form of query language to be implemented. The actual parameters in the URL would not map to attributes of your resources, but the values instead contain references to the attributes, along with other assorted things that languages have such as operators like '>', '<' and keywords like AND and OR. See for example JIRA JQL:

GET /blogs/:blog_id/posts?query=created_at=today&author=in:1,2 

GET /blogs/:blog_id/posts?created_at=today&author=in:1,2 

It may be necessary when querying for resources that you need more complex logic to determine which results are formed. In this case you need to be a little smarter in how you set up the query parameters for the filters and would probably need some form of query language to be implemented. The actual parameters in the URL would not map to attributes of your resources, but the values instead contain references to the attributes, along with other assorted things that languages have such as operators like '>', '<' and keywords like AND and OR. See for example JIRA JQL:

GET /blogs/:blog_id/posts?created_at=today&author=in:1,2 

I have a feeling though that supporting this approach would be a bit tougher to match routes against versus just using query parameters as well as determining whether a given section of the path is an 'attribute' or a 'value', but your mileage may vary.

It may be necessary when querying for resources that you may need more complex logic to determine which results are formed. In this case you need to be a little smarter in how you set up the query parameters for the filters and would probably need some form of query language to be implemented. The actual parameters in the URL would not map to attributes of your resources, but the values instead contain references to the attributes, along with other assorted things that languages have such as operators like '>', '<' and keywords like AND and OR. See for example JIRA JQL:

GET /blogs/:blog_id/posts?query=created_at=today&author=in:1,2 

I have a feeling though that supporting this approach would be a bit tougher to match routes against versus just using query parameters as well as determining whether a given section of the path is an 'attribute' or a 'value', but your mileage may vary. I mention this mostly because you may want some more fundamental filters to actually be represented on the path for easy recognition/ease of use:

GET /blogs/:blog_id/posts/new 

That request could return the same results as this request:

GET /blogs/:blog_id/posts?created_at=today