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.
7 replies on “API Only Services?”
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.
[…] Joseph Scott talks about API Only Services and whether it would be possible to have a really specialized API that wouldn’t have a web application of its own. I love that people are exposing more and more APIs to get to the data on their sites that otherwise would have to be painfully screen-scraped to be useful to other web sites, but I would suggest an alternative path to building good APIs from here on out. […]
webservices
Whenever I read API on some website, I get interested. I like to integrate, I really do. Especially when it comes to “cool” things, like flickr, or anything Google puts out. Here is an interesting read: Api only webservices? Discovered…
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
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. 😎
[…] In this increasingly distributed world, websites need to become web services, spreading themselves right out to the edges of the network. In this case, the edge is largely made up of MySpace pages, social-networking sites and blogs. The widget, meanwhile, is the blog equivalent of the API – and the more you give away, the more you get back. (Incidentally, Scoble once referred to widgets as Internet Connected Components, raising some interesting discussions.) Flickr, YouTube, Stickam, del.icio.us, Revver and many more Web 2.0 players have successfully employed widgets to drive traffic back to their own sites. eBay and Amazon take the next step by incentivizing their widgets (you earn a % of any transaction). And finally there’s the widget to end all widgets: the indefatigable Google Adsense. Ultimately, I wonder whether we even need to drive traffic back to the originating site – it seems feasible to have all the interaction taking place within the widget itself (and in fact this already happens with Adsense). This is similar to Joseph Scott’s idea for API-only services, and you could argue that Stickam and Bunchball are getting pretty close. Nonetheless, you still need a centralized site where the user can create his widgets (or do you?). […]
[…] Instead of launching this as an app first and then coming out with APIs, this is an API only service. If you’ve been reading this blog for awhile this shouldn’t come as a big surprise. I wrote about the idea of API only services back in July 2005. Amazon obviously has a huge amount of back end resources already to keep their current web offerings up, so focus on what you do well and create and API that allows others to build apps on top of it. […]