About the Author:  To change this standard text, you have to enter some information about your self in the Dashboard -> Users -> Your Profile box. Read more from this author

As we’ve been working dilligently on our public API release and the rest of the GeoIQ platform technology components, one of the design goals we’re constantly keeping in mind is that everything we do should eventually be accessible through some sort of service architecture.  Maybe I’m a little old-fashioned, but when I hear “Service Architecture” I usually think of SOAP (then I usually think about what I’m going to have for lunch, and why that spanish-looking guy is sporting a mullet).

That being said, we aren’t exposing anything through a SOAP or XML-RPC interface right now.  But why? 

Technorati Tags: API, mashup, REST

It’s not really that a SOAP or XML-RPC interface would be hard for us to implement (and indeed, it’s entirely likely that we’ll have one or both running parallel to our existing APIs if we see enough demand to do so).  In fact, it might have actually been a little easier given how simple Ruby on Rails makes implementing and testing those interfaces.

But still, we didn’t.  Ultimately, our “over HTTP” interface is a simple, REST-based model (or I could just say “It’s RESTful” if my fingers are getting tired and I was being slightly more pedantic).  Part of this was motivated by the fact that it’s just generally a little simpler to wrap around in the context of your typical mashup, but let’s look at some of the reasons why, as I see them.

First, and most obviously, it’s because what most other people are doing, and, right or wrong, that generally makes it the right choice if you’re concerned about making something that’s going to be familiar and easy to use.

Secondly, though, and the reason why it’s so predominant in mashup workflows, IMHO, is that’s it’s just so darned easy to understand and test.

I’m not trying to bash SOAP or XML-RPC, or even ebXML (well, ok, maybe a little bashing on ebXML because it’s the only one with lowercase letters), but there’s certainly something to be said for just being able to plug in a simple URL into your web browser to see what on earth the other end of your API call is doing.

Granted, for the even slightly-savvy modern software developer, it’s not a stretch to use either prepackaged testing tools or something like curl to hack together a SOAP Envelope, deliver it to the remote endpoint, and get the result back, but it’s still more work than just pasting a URL into your browser’s address bar.  Granted, not all requests to a REST/HTTP interface need to be GET requests (nor should they be, IMHO, depending on the action being performed), but practically speaking, most of them are.  It would still boil down to possibly having to create a simple template form or some quick javascript code to see what’s going on for the most part.

Back around 2000, I remember a whole bunch of talk about how this new Web Services thing was going to change everything, and allow companies to focus on their core competencies, expose those through service architectures, and through the miracle of things like SOAP, WSDL, and UDDI, we would be able to instantly create complex applications from various disparate software components spread out over a network.  There has been a lot of very cool stuff that’s happened since then that’s gotten us part of the way there, but where that idea really materialized, and only in fairly recent history on large scale, is with the mashup phenomenon.

Granted, your typical Google Maps mashup isn’t dynamically pulling in web service components based on a workflow model and interface discovery, but they certainly seem to get the job done, don’t they?  And, more importantly, they’re extremely quick to develop, and comparatively simple.

However, with things like microformats for REST starting to gain some serious traction (I’m seriously considering incorporating microformats into our stuff sooner rather than later), we might see some interesting machine-parsable interface description and discovery for mashups on a larger scale sometime soon.

The bottom line is, the ultimate goal of any API is to allow others to programatically interface with your application(s) (in that regard, I’d like to suggest a new word: “PIAing” to describe the act of using an external API).  So, no matter how robust, fancy, and buzzwordish your delivery mechanism is, it’s all for naught unless you lower the barriers to entry as much as possible.  SOAP, XML-RPC and their ilk were a giant leap forward over things like DCE/RPC in that respect, and reduced integration time and other barriers to entry by several orders of magnitude.  I think the mashup/RESTful paradigm has been able to improve upon that to the point where the “little guy” can casually interface with external programming interfaces in a meaningful way.

And while I still think that the heavier flavors of web service delivery mechanisms have their place in certain environments, the ultimate benefit not only to companies like FortiusOne, but to the community as a whole, is in enabling all those people out there with the great ideas that nobody else would have ever dreamt up to actually act on them and share them.

–
Chris Ingrassia
FortiusOne CTO

(no SOAP services or UDDI registries were harmed in the writing of this post. An ebXML document got a little dizzy, but we think it was just something he ate)

Popularity: 6% [?]