2

After reading an article on REST ("Restful Grails"), I have gotten the impression that it is not possible to truly conform to a REST style in a service that demands a lot of parameters. Is this so? All the examples I have seen so far seem to imply that true REST style services are "parameterless". Using parameters would be RPC-ish and not truly RESTful.

To be more specific, say we have a service that returns graph data for stock prices, and this service needs to know the start date, end date, the currency, stock name, and whatever else might be applicable. In any case, at least 4-5 parameters are needed to retrieve the information needed. I would imagine the URL to be something like this : /stocks/YAHOO?startDate="2008-09-01"&endDate=... ("YAHOO" is here a made-up stock name).

Would this really be REST or is this more RPC-like, what the author of the aforementioned article calls "GETful" (i.e. just low ceremony rpc)?

oligofren
  • 20,744
  • 16
  • 93
  • 180

3 Answers3

4

You can see the querystring as a filter on the resource you are GETing. Here, your resource is the stock prices of yahoo. Doing a GET on that resource give you all the available data, or the most recents. The query string filter the prices you want. Content negociation allow you to change the representation, e.g. a png graph, a csv file, and so on. To add a price, simply POST a representation (e.g. CSV) to the same resource.

The "restfulness" is not realy in the URL itself, since URIs are obscures to client, but in the way you interact with resources themselves identified by their URI

Yannick Loiseau
  • 1,394
  • 8
  • 8
  • Nice! Thanks for a good answer that delves on the semantics, which was what I was hoping for all along. – oligofren Mar 22 '11 at 23:53
1

Feel free to use as many parameters as you need to identify the resource you wish to access. REST doesn't care.

Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • But would it not be more appropriate to just call it GET-based RPC rather than REST? I mean, what is really the difference between the above and just /getStocks?id="YAHOO"&startDate="2008-09-12" ... To me this is just a thin layer on top of a method call. – oligofren Mar 21 '11 at 14:25
  • I am not really getting how a method call can be a resource - the resource, here graph data, is being created and then returned. For it to be REST-like, it seems that the graph data should have been created using PUT to be then accessible via a new URI that can then be retrieved using a GET. (ref: http://douglasfils.blogspot.com/2008/12/rest-soa-and-multi-parameter-databases.html) – oligofren Mar 21 '11 at 14:27
0

Why would you think it is not possible?

Google uses REST for their charts api, and they take alot of params:

http://chart.apis.google.com/chart?cht=bvg&chs=350x300&chd=t:20,35,10&chxr=1,0,40&chds=0,40&chco=FF0000|FFA000|00FF00&chbh=65,0,35&chxt=x,y,x&chxl=0:|High|Medium|Low|2:||Task+Priority||&chxs=2,000000,12&chtt=Tasks+on+my+To+Do+list&chts=000000,20&chg=0,25,5,5

Fortega
  • 19,463
  • 14
  • 75
  • 113
  • Yeah, but is this REST or merely REST-like RPC? I am also talking semantics here. What is the resource you are fetching in that API call? I am used to seeing examples where the resource is easily understandable as in http://bla.com/article/some-article-header - where 'some-article-header' would identify the resource that you could GET/PUT/POST/DELETE. – oligofren Mar 21 '11 at 13:46
  • I would say it is RESTful as it conforms to the rest constraints http://en.wikipedia.org/wiki/Representational_State_Transfer#Constraints – Fortega Mar 21 '11 at 14:05