lesscode.org

I wonder if it’s time to adopt a variation of Gandhi’s famous formulation: “First they ignore you, then they laugh at you, then they fight you, then you win”. It goes something like “First they ignore you, then they keep on ignoring you but you win anyway”. One nice thing about the new formulation is you get to skip the whole fighting part. I think Gandhi would approve.

On March 7, in his talk at the O’Reilly Emerging Technology Conference, Ray Ozzie, CTO Microsoft, demonstrated (short screencasts, live demo page) a method by which users can cut/copy/paste structured content between web applications and between web applications and Windows ones. Alert lesscode readers will notice that Ray’s blog post describing his inspiration and motivation for the idea bears a striking resemblance to my own post from last October. A deeper look at the screencasts, the live demo and the technical introduction remove any doubt that what Ray demonstrated, and in fact what Microsoft is offering under the Creative Commons Attribution-Share Alike license (you heard me right) is in fact the Web Application Clipboard as described in that original lesscode post and followup.

This is in no way meant to diminish the Microsoft folks’ brilliant implementation. The portable trick used to actually hook the browser’s built-in cut/copy/paste functionality is inspired. The design tradeoff resulting in a visible representation (scissors icon) of every clipboard-capable element is all their own, and quite frankly, is probably a necessary tradeoff if the Web Application Clipboard is to actually get traction. There’s a more technical analysis posted on my personal blog, but the executive summary is:

Live Clipboard (Microsoft’s name for Web Application Clipboard) is awesome and I believe sites will adopt it. I wish the name weren’t “infected” with the Windows Live brand but that won’t matter a whole lot so long as the specification is good and open. Right now though I can’t find any specification at all but I’m keeping hope alive on that front anyway (you listening Gandhi? MLK?)

What I find more interesting than that technical stuff though is the amount of mindshare this thing got “all of a sudden”. First off, note that Ray’s March 7 blog post on this subject comprises the only thing he’s blogged since the end of January. A whole month of the Microsoft CTO’s time — how many dog-years is that? Now realize that the good guys over at the Gillmor Gang podcast spent a full 48 minutes on this single topic on March 16 (Ozzie Gang I, Ozzie Gang II), most of which was spent interviewing Ray Ozzie himself. They were downright effusive. From Ozzie Gang II:

• Mike Arrington, 4:45

  Does this signify any sort of shift organization where people in microsoft who have ideas that can help the Web… that they can also get things through the politics and through the system fast enough so it doesn’t take and years?

• John Udell, 17:52

  Ray this is great. I just personally want to thank you for doing it. I think it’s a tremendous step.

• Steve Gillmor, 17:57

  Yeah, and I think that everybody is knocked out that somebody with your intuition is in such a powerful position at Microsoft. You know, bringing Microsoft into the community has been very difficult to do and you seem to be doing it.

• Dan Farber, 18:31

  I think as everybody on this call has said, we’re quite impressed with this very simple little notion that seems to be well executed and that it comes from Microsoft now really injecting itself into the big old Web community. It’s cool!

• Dan Farber, 19:13

  If you go to the desktop and you consider cut and paste, copy and paste, you know it’s everywhere… to be able to do that on the web… it’s like a big gift — it’s a contribution to the Web.

• Mike Arrington, 22:18

  I think the big story here is that we’re starting to see with Ray’s leadership that Microsoft is able to do things that seem selfless and simply good for their own sake and SSE is one example and (Live Clipboard) is another stunning example…

• Steve Gillmor, 24:05

  I think that Microsoft may well be on the threshold, whether they fully realize it or not at all levels of the organization, of winning by accepting a part in the community, and I think that’s a huge story.

Strange and wonderful times indeed.

With all this talk about High and Low REST, I noticed something in a post by Mark Nottingham:

Don has effectively made the observation that a lot of other people (especially of the Web services sort) have made; while the benefits of GET’s transparency are obvious, they’re less apparent for PUT and DELETE, so why not just take the easy (lo) road and use POST?

I think there are two answers; 1) hopefully, we’ll have some concrete benefits for that transparency some day (think offline), and 2) thinking in terms of GET/PUT/DELETE first — using POST only as an escape hatch — leads you down a path where your application will be using transparent methods a lot more than opaque POSTs.

I’ll use my first post here to repeat the ideas from Bill’s post…

I think a cargo cult of REST has indeed emerged, and I’m seeing evidence of it on the ground, far from SOA discussions. I’m seeing REST evoked as something that is inherently good. I’m seeing people ask for REST support in their frameworks. I usually know what they mean, but their requests seem to be driven by the truthiness of REST, not the utility.

For instance, I often get annoyed with URI design discussions, where people put great importance into abstract design issues that no one else will notice or care about. In HTTP (and REST) URIs are supposed to be opaque strings, so why the obsession? I call bike shed. People are tackling the pointless decisions first, because they are low-stake and easy to think about. It also comes from an inversion of logic: good things are generally aesthetically pleasing; but many things that are aesthetically pleasing are superfluous and distracting.

What’s useful is that REST design doesn’t promise anything more than it can deliver. It doesn’t promise anything general about the body of the response (except I suppose that Content-type and other metadata will be accurate). It doesn’t promise anything about the URI. The use of verbs is in part to make the URI more opaque, so instead of rewriting the URI to express new actions, you use different verbs on the same URI. GET actually means something to intermediaries. POST, PUT, and DELETE only really mean something to humans. Which is okay, but it’s not interesting architecture.

It’s not bad to use these verbs, it’s just not particularly useful. I think High REST may be the result of people who just can’t help but make architecture. Low REST is people who are recognizing emergent architecture. REST isn’t a new idea, it is the recognition of the good ideas that are already around us. And like design patterns, the description is turning into prescription, and as with patterns we are seeing people use REST to justify premature architecture — probably a much worse sin than permature optimization.

I look at a protocol like OpenID which is wedded to HTTP and HTML — and even intimately connected to those poorly-specified browsers that we all can’t help but hate — and I think that’s great architecture. It’s not great because it is pretty underneath (it isn’t), it is great because it solves a hard problem inside fixed constraints without exceeding scope. It’s RESTful at heart, but not RESTful in form.

If there aren’t concrete benefits to using PUT or DELETE over POST, then why should we care? What hard problem is made easy? High REST seems to be uncovering non-problems.

Today’s myth: limiting the number of methods is a good idea.

From an old thread on WebDAV methods:

REST encourages the creation of new methods for obscure operations, specifically because we don’t want to burden common methods with all of the logic of trying to figure out whether or not a particular operation fits the 99.9% case or one of the others that make up 0.1%.

That doesn’t mean you want to make up a new method if you don’t have to, like getStockQuote. Use GET /stockQuote/43 for that. A small number of methods will get you pretty far, but perhaps not all the way. For authoring applications, you’re likely to hit some snags. You’re also likely to hit some religion.

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.