Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

/stocks/ABC/news
/indexes/XYZ/news
/stocks/ABC/time_series/daily
/stocks/ABC/time_series/weekly
/groups/ABC/time_series/daily
/groups/ABC/time_series/weekly

Scheme 2 examples:

/news/stock/ABC
/news/index/XYZ
/time_series/stock/ABC/daily
/time_series/stock/ABC/weekly
/time_series/index/XYZ/daily
/time_series/index/XYZ/weekly

Scheme 3 examples:

/news/stock/ABC
/news/index/XYZ
/time_series/daily/stock/ABC
/time_series/weekly/stock/ABC
/time_series/daily/index/XYZ
/time_series/weekly/index/XYZ

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 :/

Thanks!

share|improve this question
    
They all seem same to me... –  Euphoric Oct 8 '12 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 '12 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 '12 at 20:30
    
@Earlz: Thanks! –  meetamit Oct 8 '12 at 20:31
add comment

2 Answers

up vote 5 down vote accepted

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:

/news/stock;ABC
/news/XYZ;index
/time_series/daily;stock;ABC
/time_series/stock;ABC;weekly
/time_series/XYZ;daily;index
/time_series/index;weekly;XYZ

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:

/news/stock?symbol=ABC
/news/index?symbol=XYZ

or even like this:

/time_series?frequency=daily&kind=stock&symbol=ABC

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.

share|improve this answer
    
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 '12 at 22:16
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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