Ok, back to practicality (I hope). Here’s what I was going on about during the lunchtime session at Web 2.0 Ireland. Adam Green brought up the problem of API lock-in. And there’s another, related problem which I know Flock is feeling at the moment. They want to allow you to save your bookmarks to whatever bookmarking site you use, upload your photos to the photo-sharing app of your choice and talk directly to your blog, whatever platform it’s running on. Yet that means they have to write interfacing code for each instance of the above, and push out an update every time there’s a new API to support. Do you realize how many bookmarking sites there are? And yes, many have APIs, but few share common APIs. Same goes for photos and blogs.
So Canter‘s answer to this was to set up broker servers which would act as a translating intermediary between client apps and web APIs (and he says his company is going to do this for certain API flavours). But then all API trafic gets routed through a centralized server. Anybody can see that’s not so smart. When I want to talk to a new API, I don’t want to talk through Canter’s server. I want Canter’s server to tell me how to talk to the new API. Then I can go off and do just that, all decentralized and pretty-like.
Now, web APIs very often talk fluent XML. So it seems possible that the hypothetical translation server could serve me an XSL transform that would tell me all I needed to talk directly to any API it supports. The idea is that these API normalizing transforms get written once, and reused in as many client apps as possible. They can be provided by the developer of the API, one of the client app developers, or anyone really. Client developers can simply target the normalized API and know that, without any effort on their part, their app will be able to talk to services which don’t even exist when they . Check out my MS Paint skillz: