In what Google describes as "spring cleaning" several APIs that appear to be perfectly serviceable have been abandoned, in many cases with no alternative being provided.
The recent news item reporting on the deprecation and closure of the Google Translate API is just the tip of the iceberg. The Translate API might be high profile but if you have spent time developing for any API then its closure is just as devastating.
In what Google describes as "spring cleaning" a set of what appear to be perfectly serviceable APIs have been abandoned.
"Following the standard deprecation period – often, as long as three years – some of the deprecated APIs will be shut down. The rest have no scheduled date for shutdown, but won’t get any new features. The policy for each deprecated API is specified in its documentation."
Most of the APIs were in Google Labs and as such you might well say more-fool the programmer who spent time developing anything real using them. After all Labs is a space were Google can try things out and occasionally admit failure and close a project. This is true, but there is also an expectation on the part of the programmers who eagerly investigate the new APIs on offer that Labs is a stepping stone to full acceptance once an API is sorted out. That is, if an API for say Finance makes it into Labs then there must be a need for such an API and one day in the future an API, perhaps not this API but something like it, For example it is not so much that the Translate API has been terminated but that it leaves programmers wondering how to work with this obviously valuable service?
The abandoned APIs come in two grades of "doomedness". First we have the ones that are deprecated, i.e. not being developed further but have no scheduled shutdown date:
- Code Search API allows client and web applications to search public source code for function definitions and sample code.
- Diacritize API integrates with Google Tashkeel programmatically. This API will add diacritical marks to the text that you send to it.
- Feedburner APIs a library of web services for interacting with feed management
- Finance API offers a variety of ways to access data programmatically, including the Google Finance Portfolio Data API and the ability to create financial gadgets.
- Power Meter API allows your customers to access their power consumption data through a secure, web-based iGoogle gadget.
- Sidewiki API allows client applications to view Google Sidewiki content in the form of Google Data API feeds
- Wave API the connection between your app and the now defunct Wave service.
No suggested alternatives are given for the above and as long as you are happy that they are not being developed you can carry on using them for the time being.
The second level of doom applies to the APIs that are being shut down on a given date:
- Books Data API allows client applications to view and update Google Books content in the form of Google Data API feeds. To close Dec 2011 but not a big problem as the Books API has some of the same features.
- Safe Browsing API (v1 only) an experimental API that allows client applications to check URLs against Google's constantly-updated blacklists of suspected phishing and malware pages. To close Dec 2011 but there is a V2 of the API.
- Translate API lets websites and programs integrate with Google Translate programmatically. To close Dec 2011 and the only alternative is the Translate Element.
- Transliterate API provide transliteration capabilities.- 3 years to shutdown
- Virtual Keyboard API lets websites and programs provide assist in text input by including virtual keyboards - 3 years to shutdown.
In most cases, despite the promise in the Google Code blog, there are no suggested alternatives and even the services that are continuing for a while carry the ominous warning that
...the number of requests you may make per day may be limited.
How limited isn't clear and this is another worry. Keeping an API working is all well and good but not it if doesn't service requests at a reasonable rate.
Seven new APIs were announced at Google I/O :
But given Google's "spring cleaning" announcement, do you trust these not to be "spring cleaned" in a few years?
How can a company develop APIs and then retire those that don't make the grade without upsetting the developer community? Clearly the way that Google is going about it isn't the right way.
Perhaps Google should think harder before it issues a new API and therefore have to retire fewer.
API churn helps no one!