REST wins, noone goes home
By Bill de hÓra under Then you win. on 19. March 2006In public and private people whom I would have never expected, are now getting interested in how to roll out in the REST style. “Restian” is the term I hear bandied about. Not “RESTful”. Not “RESTafarian”. “Restian”. I like it.
This is good news, though I’m a bit taken aback it’s happening so soon. Some people would say it should have happened half a decade ago, but I’m something of an optimist.
REST has always been a solid basis for designing distributed systems, it comes with a theory (I know! It’s crazy!), appropriate and specific to the web domain. It has not been a populist approach, which can be summed up with – “where are the REST toolkits?”.
All that is about to change. REST has won. Fire up your editors.
Have nothing in your house that you do not know to be useful.
Now what?
When REST becomes a mainstream/default development approach, as opposed to a fringe/implicit one, a couple of things come to mind on the plus ca change front. First off, I think you’ll see better support for URI design and mapping onto code in server libraries. Also, better access to headers (especially caching and timestamping directives). More awareness and support for the full range of HTTP methods and response codes. Attribute modifers and declarations on methods that have side-effects. Exception designs based around 5xx and 4xx response codes. Media type dispatching. Less emphasis on cookies, more support for digest authentication. More flexbility in LAMP stacks for writing out stuff that isn’t HTML (esp. JSON and Atom serializers). That sort of thing. Overall a gradual lifting on HTTP/REST concepts and idioms into application code.
But probably the most important initial effect is how minimal and frugal REST will seem to the working developer.
This Spartan Life
If REST has an analog in building architecture, it’s Modernism. On the web, hard lines are where it’s at, and less, really, is more.
REST is about design constraints – what you can’t say. That’s contrary to industry practice, where it’s all about about getting cool new features piled on, and to heck with principles. If anything, most developers are cynical about architecture and architects. Developers, Developers, Developers. Give ‘em what they want. Keep ornamenting the stack with pointy-clicky solution cruft.
There’ll be a bit less of that. On the web, there are less assumptions you can make and those you can make are rigid and need to be treated as invariant. Developing for the web, as opposed to developing around it, is spartan work. Coming from middleware and enterprise development, could be a bit like coming from the Victorian ornateness and richness of Ruskin and Morris to the urban cold and minimalism of le Corbusier and Mies van der Rohe. It’ll be disorienting at best.
For example, tool support will go from “non-existant” to “sucks”, initially.
All one can say is that the laws and liberties, such as they are, which govern local/LAN-based software development don’t always apply when it comes to Internet based development. In point of fact they’re often a hinderance, and there’s a history of getting burnt on bad assumptions on the Internet. You can try to make inter-network, cross-administrative systems development transparent, to look and act like middleware. But you won’t. Noone has.
The solution is invariably to take the assumptions and patterns and cute tricks away, and replace them with forcing functions in the form of design constraints that keep developer and system behaviour aligned. Even stuff that enterprise developers would tend to know, like caching, needs a different approach. Them’s the apples. REST is a collection of such constraints, formalised into an architecture.
Perhaps the key thing is education, and teaching.
I think we’re done more or less with the evangelism and technical food fights with the WS-* and Enterprise crowds. It’s time for REST to proceed on its own terms and not in contrast and counterpoint to something else. Teaching, on how to target and design with REST, particulary for HTTP as deployed, needs to ramp up. Certainly we need a few good practical books on REST/HTTP to ship.
At least one of those fine books should cover the fundamental principles of Web-centric development, the way Gamma et al did for C++ Patterns, Fowler did for Refactoring, or Norvig/Graham did for CLisp. Something that nails it. As things go, Fielding’s REST thesis is pretty accessible, a decent read even, but it’s a doctoral thesis, not a textbook.
Tickbox Gartnerfication
Hype could be a problem for REST if the “industry” gets on board with it as a commmercial factor that requires ticking off rather than some dorky engineering stuff – “Do they have REST? Check.” So will keeping an eye out for land-grabbing on the term “REST”, so it remains a crisp technical term (It has a theory?! I know! It’s crazy!).
Avoiding the descent into marketing farce, a problem that has plagued “SOA” and “WS” can only be a good thing. To be honest, I’m not holding much hope on this one.
God is in the details
Let’s be realistic. No software architecture can truly withstand implementation. REST is really great, but on the web, there is plenty of detail work to be cleared out, like push, containership, encoding, side-effected GETs, curse-of-popularity, queuing, 2 versus 4 methods, universal format junk, and authentication, among others. I could go on, it’s messy out there.
Issues like these will become more important, or more distracting, depending on your point of view, as the style gets adopted. So run away screaming from anyone who dismisses these as “just implementation details” – implementation details matter. They cost money, and break hearts.
Lot’s of work has been done. There’s lots of work to do.
PS.: in case anyone thinks there’s some kind of collective REST triumphalism going on @lesscode, there isn’t. I’ve been sitting on this post over the St Pats weekend, only to find out that Sayre and Tomayko have posted REST stuff in the meantime. You’d swear they weren’t Irish.
Michal Migurski:
After a short time lurking on rest-discuss, I’m wondering whether the REST bandwagon isn’t suffering from a fever for getting cool old features piled into an incompatible principle. REST rocks and all, but RESTful authentication? Spare me.
comment at 20. March 2006
Ryan Tomayko:
Wow.
How do we fight this? Replacing SOA or WS by REST in the press and in the vocabulary of analysts isn’t going to solve anything. In fact, if REST were ever to spin out of control in a way resembling Web Services or SOA, I’d consider going back to pouring concrete (how’s that for less code).
Our role will need to extend to that of vigilante should REST make serious in-roads with mainstream/commercial business IT. So while we’re oooing and awwing over Fielding’s profile in Time, we ought to make sure we’re calling bullshit when they get it all wrong, make outrageous promises, or otherwise misrepresent core concepts.
So I suggest we call phase one The PR Problem. That is, we confuse the shit out of everyone for a time with stuff like WS-Crossroads. Here we have Tim handing out props while at the same time being extremely critical. This will seem really weird to people used to the current Vendor / Standards Organization / Analyst / Press configuration because those guys all follow the same talking points and don’t often challenge each other. People will mistake the types of constructive conversations Tim and Daryl are having for weakness and that’s The PR Problem. But that’s okay, it’s phase one.
comment at 20. March 2006
Jerome Louvel:
For Java developers, a REST framework/toolkit already exists. It’s called Restlet and can be seen as a fully-featured replacement of the Servlet API and JSP pages. It has support for cool URIs mapping to server code, representations caching and metadata access, easy HTTP status setting, content negotiation, basic authentication and many other things. Finally, the Resltet API is very spartan (JAR size is 65 kb) and has no external dependency.
Hopefully it doesn’t suck too much :-)
comment at 20. March 2006
SitePoint Blogs » WS-DeadParrot:
[…] It’s rant time again (apologies—move along unless you’re feeling fiesty). It’s that REST vs. SOAP thing. There’s another round of debate traversing various blogs. This time it seems to be SOAP’s final death throes. If SOAP and all that makes little sense, know that you’re not alone and that you can happily ignore it and focus on smarter options. […]
pingback at 20. March 2006
Mark Baker:
I’m not too concerned, Ryan. The definition of REST remains grounded in Roy’s dissertation, unlike WS/SOA. It’s this “Lo-REST” and “Hi-REST” terminology which has me concerned, if they get any traction, becuase they aren’t rigorously defined.
comment at 20. March 2006
Avi Flax:
I nominate the lesscode.org team! Seriously, this is a great opportunity. There’s an unserved demand for exactly such a book, and you and your colleagues are uniquely and especially qualified to fill it.
Start tomorrow, offer a closed beta for pre-orders, release it as a DRM-free PDF eBook, charge $20 for rights to updates for a year or two, and I’m there!
I’m not kidding. What would it take to convince you? 50 pre-order pledges right here in the comments? 100? If you issue the challenge, I bet you’d get them. #1 right here.
I think you could even make money with this. 37signal’s eBook Getting Real brought in $33,000 in the first 24 hours.
If you put out the first definitive book on REST, that’s a strong preemptive move against The PR Problem.
comment at 20. March 2006
christopher mahan:
I too would like a good book on REST. a short book, with no screenshots. Maybe 30 pages would be great. Well written, I’d pay $30 for it.
comment at 22. March 2006
Ben Davies:
I’ve only recently been getting into REST, and I really dig it: clean, tidy, no sessions and simple authentication, moving all the “management” code of a site into Apache etc;
I still havent found anyone address my concerns about “acting” on resources. If a REST service returns a resource, then from what I can make out from all I’ve read, using a web service like XML-RPC/SOAP would be used to perform an action on that resource.
Say, for example, I GET an image from a REST service. I want to rotate that image by 90 degrees and then PUT it back. The Rotating part cannot be accomidated by REST? Is that correct? Is the PUT transfering the modified Resource, or am I passing a series of actions to be performed upon that Resource? Do I GET the image, rotate the image on the client, then PUT the image back? Or do I PUT a series of transformations to be performed on that resource?
Each explanation I’ve seen for REST treats PUT as an SQL “update”, so in that sense, the second method is suggested (I only need to PUT a series of actions to perform) and is obviously a lot more light weight (I’m only passing the changes needed to be performed, not a copy of the updated resource). However, this means that each resource must be “aware” of the different transformations that can be made to it…
I’d appreciate your thoughts!
Oh, and I too would like to see a book from you guys!
comment at 24. August 2006
Unilever Centre for Molecular Informatics, Cambridge - petermr’s blog » Blog Archive » The War on Error:
[…] Last March: REST wins, noone goes home.Well, it looks like we’re done. Which is worse, that everyone gets it now and we’ll have REST startups in Q207, or that it took half a decade? […]
pingback at 18. November 2006
tndal:
Ben Davies asks:
“Say, for example, I GET an image from a REST service. I want to rotate that image by 90 degrees and then PUT it back. The Rotating part cannot be accomidated by REST? Is that correct? Is the PUT transfering the modified Resource, or am I passing a series of actions to be performed upon that Resource? Do I GET the image, rotate the image on the client, then PUT the image back? Or do I PUT a series of transformations to be performed on that resource?”
You could do a GET of the image resource followed by a PUT of the updated image resource, as you describe.
Or you could define a separate associated resource for the image orientation and do a GET and PUT of that orientation resource.
comment at 17. December 2006
S. Potter:
As a former Java head turned Ruby evangelist I have to promote Ruby on Rails’ latest offering of ActiveResource, which is a forth coming component of the Ruby on Rails stack. The production version of Rails (1.1) already has ReSTian support for API and web producers. However, ActiveResource will take ReSTian support one step further for REST consumers in addition to producers when the stable version is released shortly under Rails 1.2. A Ruby on Rails plugin already exists for ReSTful authentication based on HTTP Basic (authentication under REST is very unfortunate, but the plugin author isn’t to blame for the history of HTTP Authentication).
I hope to add a blog entry later this weekend on my experiences with ReSTian Rails at Snakes, Gems & Coffee.
comment at 05. January 2007