The best practices for specific scenarios in RESTful Services

Question

I have two quick questions which I just want to get the community's opinions on -

1. If I have an entity which can be accessed with either an ID or a date (20110705), what's the best practice for the convention of the url used to access the entity?

   • GET : /myEntities/{date} and /myEntities/{id} ? (which the service will parse the {object} to check if it is a date or an id.

   • GET : /myEntities/date/{date} and /myEntities/id/{id}*?

2. In WCF Rest, I can also do /myEntities/?date={date} and /myEntities/?id={id}, is this a good practice of REST? In other words, is it acceptable in terms of best practices to use ?date={date} instead of date/{date}/ like it is just a simply personal preference?

Thanks in advance.

Answer 1

I feel like a lot of this comes down to preference and style.

Having said that, I'd personally prefer:

/myEntities/date/{date} and /myEntities/{id}

No need to be explicit with the ID option; it's assumed.

In regards to #2; I personally don't like this syntax: /myEntities/?date={date} if it's implemented in WCF as a URI Template - because if you have more than one parameter the assumption is the order of the parameters can be jostled around - but they can't with the URI Template. But, as standard query string parameters, this is perfectly acceptable, and is done all over the place - Google, Yahoo, Amazon, and others all use this style. If anything, this is exactly what the 'query string' was meant for - parameters for a query... which is exactly what you're doing when retrieving entities by __.

(But I'm as curious as you are about what others will say).

Answer 2

/myEntities/date/{date} should redirect to /myEntities/{id} using 301 or 307 as appropriate for your app. This reduces the possibility for data to get out of sync due to multiple cached copies, and makes it clear to clients that /myEntities/date/* is just an alternate index, not a set of independent resources (as they might rightly expect if you did not redirect, due to the hierarchical nature of HTTP URI's).