I saw an interesting article by Mark Little (linked on Scott Banwart’s Blog) about how important REST is for the “cloud”, anyway?
For a while, I’ve been wondering about how useful strict adherence to REST really is. The Interwebs were built on GET and POST, after all. What does PUT really add to the mix? Further, the usefulness of GET is mitigated by cache control parameters. In most of the dynamic web applications I write, I have a set of headers that I throw in that tells intermediate servers not to cache, or to immediately expire any cache they do keep. 😉 That’s usually because the data the GET is returning is either calculated or ephemeral, and each time the client does a GET, they need to get the current view of the data.
In one case, we were sending legal documents around, so I had to do all sorts of testing to make sure that even the browser didn’t cache the files locally on disk.
And, as if to prove Mark Little’s point, the “cloud” team that I just left hired a noisy buffoon who labeled himself a Cloud Expert, and every time he designed a REST-ful API, all the URLs were just chock-full of verbs and commands and all the patterns that break RESTfulness. When I brought it up, he didn’t even understand the issue, but I could tell by the darkened expressions around the table that others had been having the same feelings. (I just smiled and let him to do his “expert” thing, and shortly after got the hell off that team — I’m not a REST purist, but I do have an aversion to open stupidity.)
All that really makes me question the worth of a purist’s take on REST. I mean, given
* We’re often not using GETs in a cache-able way
* The web was built with POST and the absence of PUT
* The painful and unending impedance mis-match between REST and CRUD
* Even now, few of the projects I work on implement DELETE because of the complexity of cascading deletes, or because of referential integrity between remote systems
* REST is heading in the direction of specific, propietary media types, rather than broad, generally-supported media types like “text/plain” or “application/xml”
* Every REST project I’ve seen ends up putting verbs in URIs after all
* The non-adoption of strict REST design by the biggest players in the industry, as cited in the article above
…what is the long-term prognosis for REST?
It reminds me of Class Inheritence in OO. That sounded wonderful on the small scale. If you talk about Bird, Duck, Penguin, it makes for a cute and clever example. But as it scales up to class heirarchies involving dozens or hundreds of classes, it turns into a nightmare of complexity and rigid dependency. I have the feeling we’re headed down the same path with strict REST.
Having a nice, clean ideal like strict REST is wonderful. But at some point you have to listen to what the Universe is telling you. If the Interwebs were not built on REST, and the larger body of software developers are not adhering to REST now, what is the message we should be getting?
On an about-to-collide tangent, I read an interesting article lately about “moving the processing to the data” instead of the other way around. The author’s point was that in any corporation there are thousands of desktop machines that are sitting idle, but we still insist on shipping data off those machines to a central datastore, and then we process the data there. Which is, of course, hugely wasteful. He was advocating finding a way to move the processing to the data — a familiar call to action, but still appealing.
If I can recover the link to that article, I’ll link it here.
This REST business is a good exercise in clean practices for designing a network-oriented API, but in the end I think it will be influential rather than dominant. As the ideas driving “cloud computing” emerge, I think there will emerge bolder, more lasting standards and methodologies for how we harness distributed processing power and distributed data.