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!
3
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.
1
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.