In 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.