Kind of a REST lightweight here... Wondering which url scheme is more appropriate for a stock market data app (BTW, all queries will be GETs as the client doesn't modify data):

Scheme 1 examples:


Scheme 2 examples:


Scheme 3 examples:


Scheme 4: Something else???

The point is that for any data being requested, the url needs to encapsulate whether an item is a Stock or an Index. And, with all the RESTful talk about resources I'm confused about whether my primary resource is the stock & index or the time_series & news. Sorry if this is a silly question :/


  • They all seem same to me...
    – Euphoric
    Oct 8, 2012 at 20:26
  • In the long run, it won't really matter. All 3 of these seem fine to me, with my personal favorite being scheme 2
    – Earlz
    Oct 8, 2012 at 20:29
  • @Euphoric: In other words, they're all valid and it's up to me to pick whichever one I like? (bc they're not really the same).
    – meetamit
    Oct 8, 2012 at 20:30

2 Answers 2


The three approaches are roughly equivalent to each other, regardless of the way that you structure your hierarchy. This leads to an interesting observation: there may be no hierarchy there after all.

Consider this alternative:


This URI structure gives away an important property of your service: the resources that you expose are not hierarchical in their nature, so any meaningful UIR would do.

You can take this to the max, and make your URIs look like this:


or even like this:


Though not as nice-looking, these alternatives make valid choices as well, and provide more flexibility in the way the clients can build their requests by allowing the identifying information come in arbitrary order.

  • Absolutely: although the distinction between stock and index is needed (because their ids can overlap), the hierarchy of indexes containing stocks is meaningless. In fact, the need to specify the "kind" only arose later in the project, due to some limitation. Making the order arbitrary, as in your last example, is an advantage that didn't occur to me till now. I don't personally care about the aesthetics of the url, but I did worry that the reliance on URL params would anger REST purists, which is why I got into this deliberation in the first place. Thanks!
    – meetamit
    Oct 8, 2012 at 22:16

TL;DR: Scheme 3

If you only ever support the individual "leaf" resources then it doesn't make much of a difference. If you consider extending functionality to GET'ting collections; then I think scheme 3 becomes the obvious choice. It creates a more usable hierarchy for querying. You can get all the relevant news for that user, or possibly filtered by any attribute. The time series data could also be made more interesting if filtering was supported so I could query for all entries that went above or below a threshold.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.