API Only Services?

Along with most folks, I’m thrilled when I see APIs made available for cool services. It seems to me that this what Tim O’Reilly means when using the term Web 2.0. With open and usable APIs others are free to create entirely new “products” by mix and matching APIs from various sources. This is great because it allows so many people to be involved in the process, not just the companies who came up with the original services. The more people involved, the bigger the pool of imagination from which new products and services can emerge.

For the most part, a service is made available (like Google Maps), reaches some level of popularity and then, sometimes much later, an API is made available for others to use. This isn’t always the case, Yahoo!’s My Web 2.0 was announced and then made some initial APIs available on day one. What I haven’t really seen much of is APIs being put out first and letting services grow around them.

So are we going to see API only services in the future? I’m not sure, but I’d argue that API only/focused services are the way to go in the future. Just like job specialization allows companies to scale in ways not possible before, I believe that API specialization would allow the Internet to scale in ways we’ve yet to see. Let’s take a basic example, spell check. Virtually anytime you use a textarea on a web page it would be helpful to offer a spell check feature. When Gmail offered an AJAXified spell check feature we were all impressed and wanted to use it in other places. But who wants to recreate the wheel for spell check every where that it might be handy to have? In part the popularity of AJAX has solved some of this problem, by providing frameworks that make adding such features to web pages easier.

Going down one more layer, what actually does the spell checking? Most languages have hooks into Aspell that allows them to does this. But does everyone who wants to use spell check on their website need to have Aspell installed and working with their language of choice? Why isn’t there a central service providing a spell check API? Why can’t they simply make use of a publicly available spell check API (via REST/SOAP/XML-RPC, etc)? This wouldn’t have to be limited to web pages either, any application could simply talk to the spell check server and get the information it needed.

There’s no reason to only have one spell check server, competition is a good thing and if one was offline for awhile then having others to fall back on would be helpful. For that matter there’s no reason why you couldn’t have a local spell check server just for your company/office, as long at it made use of the same APIs so that client applications would be able to use as a drop in replacement. Imagine being able to enter a URL in Microsoft Word in a settings area and have it make use of your company spell check server, how cool would that be? For better performance caching could be done either at some local network server and/or on the client application. In many ways this is the Web/DNS model all over again, but for APIs.

If we really are going to fully embrace the capabilities that the Internet makes possible I think that specialization at the API level is where things will go.

3 Comments

  1. Hmm… now someone just needs to find a way to pay for these services. Advertising probably isn’t going to work here. Micropayments are the new way to do this I belive. I think Google is working on something like that, and PayPal better be working on something or it will miss out.

  2. You want a killer service? US Sales Tax calculation. The government expects it’s citizens to pay correct taxes. The only way to calculate correct taxes sucks. It sucks really, really hard. I want the @#$&*%! government to publish a ->>> FREE

  3. apart from paying for such services, which has been a known problem for a long time now, there are also privacy concerns here. Outsourcing many seemingly simple things like spellcheck can have interesting consequences – would you like spellcheck.example.com to see everything you write on some textbox here and there or in your local editor?

    I didn’t think so. 8-)

Leave a Reply

Your email address will not be published.

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2014 Joseph Scott

Theme by Anders NorenUp ↑