Lecture 29: More Thoughts on REST
Agenda
- Distillation of Duncan Cragg's views on REST
- A quick look at an anti-REST screed
Who is Duncan Cragg
- A technology consultant educated at University College London and Imperial College
- An advocate of declarative programming. For instance, writing HTML is an example of declarative programming, and Duncan believes that the best way to do Ajax is declaratively. The argument being that the Web's declarative nature should not be broken just because you want to have two-way dynamic data featured on your website.
- An advocate of REST, especially with respect to how it builds on and mimics the Web's extremely successful software architecture
STREST
- STREST is a term introduced by Cragg to describe a bastardization of REST by Web 2.0 companies that stands for Service-Trampled REST
- He describes the problem basically as APIs that are abusing HTTP to carry function calls which he claims can break the GETable Web and the POSTable Web and further claims is an attempt to create a “World Wide Web of Functions” which is counterproductive since a “World Wide Web of Resources” already exists and spans the globe.
- Symptoms of STREST
- Single URLs to GET and POST to - the 'service' endpoint (http://www.flickr.com/services/rest/).
- Similarly, function URLs (e.g. https://api.del.icio.us/v1/posts/add)
- Arguments to the 'function call', perhaps 'method' (flickr.groups.pools.getPhotos, flickr.blogs.postPhoto, etc), access key, etc.
- Internal ids as arguments (photo_id, etc.)
- Use of GET for 'function calls' that cause changes
- Use of POST for 'function calls' that only read data
- POSTing an entire 'function call' in XML, complete with name and arguments, to the service URL
- Breaking the GETable Web
- The main point that Cragg discusses is that people who implement STREST are thinking in terms of function calls, and once you do that in an HTTP/Resource context its really easy to slip away from the Web's design and start breaking its fundamental properties of being able to cache, index, and bookmark (link to) resources
- First, an exception: The following URL follows REST design principals:
- GET http://strest.com/api?call=getPic&pic_id=42
- This is clearly a function call, getPic(pic_id=42), but at least you can cache it, index it, and link to it.
- It would perhaps be better as: http://restful.com/pics/42
- The problem is that if you think of the URL as a function call, you will be tempted to put other parameters in the URL and then deciding that its not worth it and just switch to POST and pass all of the parameters in the POST body. This has the side effect of breaking the properties of being able to cache, index, and link to the resources in your Web service.
- He states
This is an aspect of the inversion between function calls and resource identification: service interfaces naturally publish function calls and hide data, where the Web publishes data and hides the mechanisms that animate them.
- Breaking the POSTable Web
- Cragg claims that the use of POST to handle state-changing function calls comes with two costs: scalability and interoperability
- With respect to scalability, the function call is a bottleneck over the resources being changed. “All calls that change internal data have to go through the same host/port/path combination”
TO BE CONTINUED…
Anti-REST Screed
- Ian Foster posted (on Nov. 12, 2006) an Anti-REST screed called Web Fundamentalism
- His main point is that people who evangelize REST tend to exhibit aspects of fundamentalism, in particular the view that simple rules must be applied to all situations
- His background is in Grid computing and he claims to have had great success with Open Grid Services Infrastructure and other WS-* specifications, pointing to one of his papers called Modeling and Managing State in Distributed Systems: The Role of OGSI and WSRF
- Its interesting to note that he states that he first encountered fundamentalism in computer science when he “hung out with declarative programmers”. Duncan Cragg is, as I mentioned, an advocate of declarative programming! Perhaps SOA and REST just appeal to different types of people?
