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.

Comment RSS - Both comments and pings are currently closed.