lesscode.org

Dare Obasanjo has a great post on allocating resources for XML, HTTP, and REST. The idea is that Don Box has given you an engineering budget, and you’re not allowed to steal money from the Web Services department. It goes like this:

You have $100 engineering dollars to spend. No matter how many millions we’d actually wind up spending, we use $100 as an easy number for people to keep in their heads.

There are well over $100 dollars worth of features you want.

The challenge is in determining how to spread the $100 in a way that produces with the most aggregate value.

I find myself in near-total agreement with Dare, except that I would take all that C# money and spend it on IronPython. This is lesscode, and we don’t believe in 48-character method names that VisualStudio autocompletes for us. :)

I find it particularly interesting that he allocated $40 to “better support for consuming XML in the browser.” Well, what a coincidence. I’ve been spending some time sheparding a JavaScript SAX interface through the Mozilla process. Now, I certainly don’t have any decision-making power, and I don’t speak for Mozilla, but wouldn’t it be cool if Microsoft exposed SAX to JavaScript? That could speed up a lot of AJAX. MSXML SAX objects are already available to client code as ActiveX objects, but you can’t write a ContentHandler in JavaScript for Internet Explorer. Bummer. Why not? AJAX developers are getting pretty good at event-driven code.

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.

I’d like to follow up Ryan’s post with a quick note on what they call high REST. The definition seems to be using GET/POST/PUT/DELETE. Those are the four significant methods in RFC2616, but every other version of HTTP has contained additional methods, and there are no widely deployed applications that operate that way. WebDAV is a bad example, since it doesn’t use POST, and defines many additional methods. LOCK, COPY, MOVE, and other methods are required to make it a useful protocol. The Atom protocol uses only those four methods, but it hasn’t seen wide deployment (though it may).

This reality sort of pokes a hole in the argument that “high REST” standardizes what is already known to work. That doesn’t mean it won’t work, but GET/POST/PUT/DELETE advocates who claim they are pointing out the obvious are actually making a religious argument, and that poor thesis is playing the role of C-3PO in the Ewok village. It’s unproven technology, and it should be viewed with healthy skepticism.

Discussion on REST seems to be moving in a constructive direction all over the place with Tim Bray and Don Box both contributing. I think Dare Obasanjo’s notes from a talk given by Google’s Nelson Minar almost a year ago may have put some valuable terminology behind ideas that have been floating around for some time and may have even brought us to a place where we can have an actual conversation about this stuff:

To begin he defined what he called ‘low REST’ (i.e. Plain Old XML over HTTP or POX) and ‘high REST’. Low REST implies using HTTP GETs for all API accesses but remembering that GET requests should not have side effects. High REST involves using the four main HTTP verbs (GET, POST, PUT, and DELETE) to manipulate resource representations, using XML documents as message payloads, putting metadata in HTTP headers and using URLs meaningfully.

The definitions of low REST / high REST could be tweaked a bit (maybe they were when I wasn’t looking?) but I do like the idea of putting terms we can all agree on to the subset that’s the reality behind most of machine/web interfaces that seem to be working today. POX isn’t that term because it unnessarily constrains the media type; “low REST” should include the mostly non-XML web (i.e. the text/html, image/*, text/css, text/javascript, etc. web) where it conforms to the constraints of GET and POST.

The reason I like this approach is because it could remove the artificial and often harmful separation made between the web people interact with and the web machines interact with. Exposing resources for machine consumption isn’t any different than exposing resources for human consumption until you get down to the media type (and not then if you subscribe to Microformats). That is, some form of hyper-media (links / URIs) and a simple, universal interface (HTTP) are the really big wins you get with REST because those things are what creates the possibility of having a hugely distributed and uncoordinated system of interaction. The choice of document format is something else entirely and the decisions there ought to be based on a whole other set of concerns.

If I cared at all about the term anymore, I would go so far as to say that anything conforming to the constraints of at least one HTTP method and that also exposes references to other resources using URIs should be considered “a web service”. But “web service” has been defined to death and it doesn’t seem to be helping.

The first time I heard someone attempt to describe the GET/POST subset as something we should pay attention to was Michael Champion on xml-dev. This was usually thrown out when someone championing REST used the “REST is the web and the web is working” argument (I use that argument to this day, btw). Michael would often be the one to point out that it wasn’t exactly true and that a subset of what REST describes seemed to be working well on the web (GET/POST, URIs, caching), while another subset was clearly—sometimes knowingly—being violated (GET w/ side-effects, uncool URIs), and yet another subset was used only rarely (PUT/DELETE/OPTIONS, content negotiation).

Not being able to distinguish which of these subsets of applied REST one is refering to is hurting our ability to have meaningful conversations about this stuff. For example, consider the following conversation; I’ve seen it hundreds of times now:

Restafarian: 80% of developers use the XXX REST API because they find it easier to deal with.
Tool Vendor: That’s not really REST. It only uses GET and POST and breaks rule #5034
Restafarian: Oh yea, well SOAP/WS-* sucks.
Tool Vendor: Go write some PHP you dirty hippie!

I’d like that to stop happening.

But I don’t think adopting wrong or ambiguous terminology is going to help either. I’d like to register my nits with the few sentences that Dare provided and see if anyone else is thinking along similar lines.

To begin he defined what he called ‘low REST’ (i.e. Plain Old XML over HTTP or POX) and ‘high REST’.

Like I said before, POX is kind of, ummm, bad, I think. It focuses too much on the format. XML is not why the web is working. URLs and HTTP is why the web is working. HTTP and URLs work so well they’re even capable of being useful in spite of complexities in media-types based on XML.

Low REST implies using HTTP GETs for all API accesses but remembering that GET requests should not have side effects.

Fully constrained GETs are really important but POST should fall under low-REST too. By the definition above, low-REST can never modify anything. Throw POST in there, it’s a big part of the present day human/web and is likely to play a bigger role in the machine/web.

High REST involves using the four main HTTP verbs (GET, POST, PUT, and DELETE) to manipulate resource representations, using XML documents as message payloads, putting metadata in HTTP headers and using URLs meaningfully.

I think we ought to downgrade XML to a “bestcommon practice” or something. Microformats and JSON are two notable examples of non-XML representations that seem to be working quite well and are absolutely capable of being used high-RESTfully.

I’m pretty sure I’ll always be a high-RESTafarian but I could definitely see myself coming out as a lo-RESTafarian as well if some of this were grinded out a bit more.

SYS-CON Media publisher/editor Jeremy Geelan, a fine chap who interviewed The Father of Java just the other day, contacted me about re-publishing Gosling Didn’t Get The Memo on sys-con.com. This is the same site that published Gosling’s original remarks.

It took me about five seconds to agree, within an hour we were sharing the front page with the original Gosling quote, and we’ve just now broken into the top three most heavily read articles on the site for the day. The republished post is here and is pretty much an exact copy (comments and all).

So yea, I’m stoked.

I should also mention that there was likely some back-channel prodding that helped lead to this. Adaptive Path’s Jesse James Garrett was panelist at the SYS-CON hosted Real-World AJAX event earlier this week in New York (see: Geelan interviews Jesse). From what I can gather, Jesse played no small part in getting the article picked up.

Huge thanks to both Jesse and Jeremy from lesscode.org.