REST best practice for accessing a resource using two attributes

Question

Hi All

I have unique RESTful resources which can only be identified in the system with two attributes. What I want to know is what is the best practice approach to do this.

The resource is identified with an id attribute (which is not unique) and a name attribute (which also is not unique), however the combination of both attributes is unique.

Currently our URI looks like this, but this doesn't seem right:

http://www.domain.com/somepath/myresource?firstid=1&secondid=aname

I was thinking would it be better to combine the two attributes such as 'firstid-aname' as this seems to describe the permanency of the resource. e.g. so that you get a URI:

http://www.domain.com/somepath/myresource/firstid-aname

Or would it be better to do something like this, which I've seen else where:

http://www.domain.com/somepath/myresource;firstid=1;secondid=aname

Any suggestions would be greatly appreciated. Thanks

Answer 1

I think you first example is not that bad. It could be that some people think of it as not really clean because of the various non-alphanumeric characters. Quite often you'll see something like this:

http://www.domain.com/somepath/myresource/firstid/1/secondid/aname

However since REST is an architecture and not a standard you are free to do as you wish. Personally I don't think URIs necessarily have to be very pretty.

edit before someone complains: Of course it's never bad if they are. Most of the time they are read and emitted by programs which don't care. Pretty URIs are better for debugging.

Answer 2

For RESTx, we allow the definition of 'positional parameters' in the URL. So, you could write something like:

http://www.domain.com/somepath/myresource/1/aname

But you always have the option to also just specify ordinary query parameters in the URL, like so:

http://www.domain.com/somepath/myresource?firstid=1&secondid=aname

Which option works best for you may depend on the sort of client applications you write. RESTx, for example, does not force you to use one or the other, you can use both of them at the same time.

But consider this: Some web caches and other 'smart' web infrastructure elements have issues with parameters in the URL. They might ignore everything after the end of the path (such as query parameters) and therefore, your RESTful resource is not cached or otherwise treated correctly. This might not be an issue in smaller organizations, but if your RESTful resource is exposed on the Internet, this is something you might want to consider.

I like to follow the principles that the URL path should identify the resource itself, while any parameters are only used to modify the output for this one request. Of course, if you always use the same query parameters then you might just as well allow them as positional parameters in your URL.