I’m certain that most of what I have to say here will be related to software architecture. It’s what I spend my days working on, and while you’d think that it would be the last thing I’d want to spend my nights writing about, it’s a topic on which I have a lot of opinions and insights to share. While I’ve had a variety of roles in my career, I’ve been largely focused on loosely-coupled, hyperlink-driven systems based on standard protocols and formats — in a nutshell: Web-inspired software architecture. I imagine that this will be the prominent theme here (though I don’t have long term plans for what I am going to cover beyond the first few posts). The title of this blog, “linked, not bound”, is meant to reflect the nature of the subject matter, though it incidentally describes the format as well.
Blogs are a very personal form of communication. Because the writing reflects the views of the author it often tells you as much about them as it does about the subject matter. I think that this, my first post, should elaborate on not only the subject of this blog but also my relationship to the topic. When I used the term Web-inspired software architecture above, I was not refering to the architecture of the Web itself — the world of HTML and desktop browsers, but to the Web’s architectural style. Unless you’ve been hiding under a digital rock, you’ll know that I’m referring to Representational State Transfer or REST.
And so at this point, I need to do a little work to keep your attention. Most folks these days are desperately trying to reduce their data intake by unfollowing or unsubscribing from low-value information sources. We’ve all got busy lives and if a blog doesn’t offer something new and unique then it’s not worth the reader’s (nor the writer’s) time. REST certainly isn’t new; in fact it’s probably in the waning stages of the hype cycle by now. But that’s the problem: the subject has not just been beaten to death, it’s been beaten beyond recognition. A lot of the content covering REST really misses the mark or is just plain wrong — a problem that snowballs as folks learn from this misinformation and then spread it in their own blogs, or worse, crank out half-baked APIs and mislabel them as RESTful.
Not all of the content is bad though; there are a lot of smart people out there that do understand REST pretty well and are writing great material on the topic. But even those that have a good grasp of the theory often have a hard time applying it to their own systems. A lot of the advice available to implementers of RESTful systems is about what they shouldn’t do: don’t use WSDL or WADL, don’t put verbs in URIs, don’t define the API in terms of a server-side object model, don’t use POST when another method is a better fit, and so on. But the guidelines for what you should do often amount to: use HTTP correctly and define your interface in terms of a hypermedia language. While learning HTTP is relatively straight forward if you’re willing to spend the time, designing a hypermedia format can be challenging — especially if you haven’t been exposed to a wide variety of markup languages. Also, as very few developers have worked on any sort of hypermedia browser, they are often completely lost when it comes to writing a RESTful client.
I think that, because of my background, I have some insights and advice to share on these topics that others might find both interesting and useful — that’s why I’m writing this blog. I first began practicing REST-based software design almost 10 years ago — before I knew what REST was. Back then I was working on what is known as a “Voice Browser”. If you’ve called a 1-800 number in the past few years and reached an automated voice system then you’ve likely used a voice browser. These days these systems are primarily driven by a markup language called VoiceXML that defines the interface. When the system takes a call, the dialed number is translated into an HTTP URI that is used to fetch an initial VoiceXML page that tells the system what audio prompts to play back to the user. It also tells the voice browser how to fetch the subsequent page based on the user’s voice or touch-tone input. If this sounds a bit like an HTML browser but for voice interfaces then you’ve got the idea.
I first heard about REST back in 2002. When Google released their SOAP API, it came under fire from a lot of the early REST proponents and the resulting argument made its way into tech news and blogs (looking back, it’s strange to see Sam Ruby on the SOAP side of the fence). It initially got my attention because I knew and respected a couple of its strongest advocates. Paul Prescod was in my class at the University of Waterloo; I didn’t really know him personally but I knew he was a smart guy. Also while at UW, I interned at a company called Teleride Sage where I was fortunate to have Mark Baker as my manager. Even though I only worked for him briefly, I remember learning a lot from him. I also recall him being pretty excited about this cool, new “Mosaic” program that he thought everyone should check out. So when these guys began screaming that the entire tech industry was heading in the wrong direction with SOAP, I was very curious to see what they were on about.
As I read more about REST, it resonated with me because I could relate it to the work I was doing in Voice Browsers. For example, I’d had debates with co-workers who were pushing to replace simple GET requests with SOAP where I’d argue that “it’s supposed to work like a web browser!” REST finally put a name to the concept of a system that works like the web. It provided a framework to help guide design work and got me interested in the foundations of software architecture — another topic that I plan to write about.
I spent a number of years working with VoiceXML from all different angles, building browsers, applications and tools. This included working on a system based on VoiceXML’s sister language: CCXML. I frequently refer folks to CCXML as it is a language that is worthy of attention. Many REST practitioners struggle in trying to apply the style in contexts where the client is not directed by a human being through a user interface. CCXML is a standard hypermedia format that provides similar client-server decoupling as HTML and VoiceXML but unlike those languages, does not drive a UI. I intend to spend quite a bit of time here discussing CCXML and what can be learned from it.
A few years ago, I switched gears to work at a company that put ads in casual games and was able to apply RESTful principles in an entirely different domain before moving back to the telecommunications space. I only spend a small fraction of my time working on RESTful systems these days — my core focus is now on SIP communications platforms. This provides yet another link-driven architectural style to study and discuss here. I will definitely try and make it relevant for webby folks and do my best to help them appreciate SIP — it is certainly in their HTTP comfort zone.
I think my experience, while not entirely unique (there are quite a few VoiceXML & CCXML platforms out there), is a little off the beaten path for most web-centric folks. I’ve found that I often have a slightly different take on things than folks who’ve only dealt with HTML, Atom and the Semantic Web. I hope that this forum allows me to provide you with content that is both interesting and valuable, and generate some good conversations as well.
linked, not bound 
May 24, 2010 at 8:08 am |
Cool intro, Andrew — you’ve got me hooked. Very interested in your experience/thoughts about voice browsers and SIP.
Hope you find the time to write down all the interesting stuff you mentioned.
May 24, 2010 at 10:46 am |
[…] Introduction – Introductory post of a new blog to keep an eye on — Andrew will be writing about his thoughts and experience with voice browsers, SIP and other hyperlink-driven systems. (by Andrew Wahbe) […]