lesscode.org

There’s a big battle of words raging on to define what the hell we’re doing and why we’re doing it all wrong.

Are Web services on the Web, or do they have to use SOAP? How is low REST different from high REST? Does XML/HTTP work better if we call it POX? When is AJAX not AJAX? Who owns the semantic landscape?

There are also a lot of people building applications, that don’t have time to argue how you call it or what it means, just as long as it works. We call them, “the pragmatics.” This post is for them.

When it comes to designing Web services, there’s a few choices of architecture style, and stacks of technologies to choose from. It’s still undecided which one will rule them all, the race if far from over. Most people who write about that stuff hope their horse is the winning one.

I’m no exception. So I’m going to play pundit and tell you which architecture style I think works best for the Web, which technology stack I prefer to use:

• Architecture style: use the simplest most common solution to solve your problem.
• Technology stack: see above.

XML over HTTP (can we please not use an acronym that means a disease?) is great for moving structured data around, and shines at encapsulation. Its loosely coupled document style has too many merits to mention. Except when you’re building a UI that needs to talk back to the server, where tight coupling is good enough, and too much abstraction means you’ll never deliver on time.

RSS is a wonderful way to stream data updates from server to client, not to mention the magical combination that are blogs and feed readers. It’s the ultimate query API. Except when your UI is trying to query the number of unread e-mails in your inbox, and you find out that RSS is anything but simple.

Microformats are amazing in their beauty and simplicity, and let you easily microchunk your content. Until you fall in the 80% of problems they were never intended to solve and… well, just don’t solve.

JSON (not to be confused with Jason, though they both love AJAX) is the simplest form of API you can think of, concise and easy to use. It’s a wonder it wasn’t invented earlier. Except that it’s tightly coupled and still envious of what XML can do for you.

AJAX is great even though almost everybody is using it for HTML. But let’s not get too tangled up in detail, acronyms are not for describing but for branding.

There’s nothing like REST, it powers the Web (can we get a logo for that?). You’ll just have to ignore all those big name Web sites we all like to mention that use cookies for the benefit of their users. And all the REST APIs that violate more constraints than a drunk driver speeding down the wrong side of the road.

RDF is semantic bliss, it gets semantics right and has a thoughtful model for representing and querying it. You can do amazing things with it. But most likely your semantic data is not RDF, and still happens to work, and you’re cursing every time you need to fix Firefox configuration files in all their semantic glory.

The Web thrives not because it uses a strict architectural style and a coherent technology stack. It thrives because so many sites pay little attention to REST and choose to focus on their users instead. It thrives because malformed HTML pages include GIFs and PNGs and Flash and badly written JavaScript that just works. It thrives because people go on the Web to send e-mail, IM, do VoIP and trade BitTorrent files.

The search for the holy grail, the one technology to rule them all, is as old as technology itself. I’m fine knowing we’ll never settle the score, never know whether vi is truely better than Emacs, or whether Eclipse shadows them both. But unless you’re a vendor making money on one horse, it doesn’t matter to you.

If you’re a pragmatic developer, you have one tool in your toolbelt that always wins the day. It’s the ability to think, ask questions and make choices. To choose solutions that are best for the problem you’re tackling right now. And to keep learning. Because there will always be some new technology that’s better at solving some use case or another.

The only architecture that matters is the simplest one you can get to solve the problem at hand.

This post: written in Vim, formatted as HTML, available over RSS.

• The Meme.
• The Architecture.
• The Wikipedia Entry.
• The Tag.

Recently David Heinemeier-Hanson asked “How do we fork the word enterprise?”. This will do for now.

via Patrick Logan and Mark Baker

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.