In terms of the “technically” correct REST URI, there is no difference between using query string parameters or not. RFC 3986 says:
The request component contains non-hierarchical data, which together with the data in the path component (section 3.3) serve to identify the resource
That's why it’s hard for you to find the ultimate “best practice.” Having said that, many REST APIs embed several parameters in a URI without using query strings. For example, to determine the make and model of a car, you will see websites with a URI as follows: cars.com/honda/civic. In this case, it is very obvious that the relationship between 2 and so, having everything in the URI, is “hacked”. In addition, it is much easier to adhere to the string approach without asking when you have only one parameter that uniquely identifies the resource; but if it is something like a search query, I would probably save it in the query string. In this SO question, there is an interesting discussion about various approaches.
In the above example, I will stick with the query string parameters. Although REST usually has more intuitive URLs, it really is not like REST. REST is more associated with hypermedia and HATEOAS .
Steve michelotti
source share