There is not a week where I don’t see developers discovering that a given API has been deprecated. Today’s disappointment (at least in my twitter stream) comes from the Google Chart Tool API.
Don’t get me wrong. I feel for these developers and I would be upset should the same problem happen to me. Now, being upset is great. Learning how to prevent that is better, and I believe there are many ways to avoid that. The most obvious one is to re-invent the wheel as suggested by Adactio.
Next time someone asks why I’m reinventing the wheel, I’m telling them it’s because the wheel API is being deprecated. developers.google.com/chart/terms
— Jeremy Keith (@adactio) May 15, 2012
That is obviously not always possible… and is probably not the right solution either because re-inventing the wheel can be a real rabbit-hole which may take you to building a power grid!
Another solution is to favor protocols over APIs. To over-simplify things, an API is just a combination of uni-laterally decided upon protocol and an endpoint. The Twitter API is the twitter protocol used against twitter.com. Got it? This is what Status.net understood when they decided to write a compatible API… for which you would just have to change the endpoint from twitter.com to status.net. That worked until Twitter changed its API.
Now, if developers relied more on protocols, that means that when a providers disappears or deprecates a service, developers could just change the endpoint, without changing anything in their code to make sure everything keeps working. Re-using code is the most satisfying feeling for many developers.
Want an example? Last week, I got tired of myopenid.net inability to stay up. I used them as a provider for my personal openid endpoint. Changing the provider was as simple as changing the openid2.provider href in the HTML and I was done.
When you decide to work with a given’s service API, please tell them you want their API to become a protocol, something for which you are a stake holder, that you can help improve. Also, if there is any open protocol or any schema that does what this API aims at doing, please convince them that it’s way to go, that this will make the web better and that will make your code more useful to more people :)
At Superfeedr, we’re obviously big promoters of protocols (XMPP, PubSubHubbub, ATOM, ActivityStreams) over APIs, and we obviously kept the same philosophy for Msgboy.
Addendum: what makes me even sadder about this story is that Brad Fitz, who wrote the Social Graph API is the one who told me first about protocols being better than API..; and guess what? The Social Graph API has been deprecated as well. :(
Comments