It’s a natural part of the API lifecycle for some to no longer be available. According to the ProgrammableWeb directory, about 13% of those that were once alive are now considered “deadpooled.” Of the companies tracked in the directory, Google tops the list with 33 discontinued APIs. However, it also has the most APIs. Percentage-wise, a handful of phone carriers seem most apt to kill APIs.
The table below shows the companies with the most APIs removed from active service.
|Company||Total APIs||Dead APIs||% Dead|
It’s not surprising to see big name companies on this list. Those with more APIs are much more likely to have discontinued more APIs. When broken down by percentage, Google, Yahoo and AOL (the top three by number of dead APIs) are still far above the 13 and 11% from their peers Microsoft and Amazon.
Truly impressive is this list of companies with more than 10 APIs and not a single one in the deadpool: eBay, Sapo, AT&T, New York Times, OCLC and Data8.
Developers feel the pain of an API that goes away. Integrations in production mean broken apps unless code is updated. Mobile apps cannot usually have new code pushed out to every installation, something that happens automatically with web apps. Mobile apps that aren’t updated will be broken forever, with the developer likely getting the blame.
Rewrites can be difficult, especially when there is no obvious replacement. Developers who have been burned are more likely to carefully choose a provider and are more willing to pay if it means the service can stick around. In the past, it seemed safer to choose big companies the the budgets to sustain APIs for the long haul. Now even that isn’t a safe choice, given the well-publicized “spring cleanings” of Google.
There’s pain for those running APIs, as well. Many times there are in-house developers that are supporting an API. While these evangelists understand the pain of their audience, they also understand the internal decisions that force the API closures.
The flip-side of API euthanasia is that it allows the company to focus on the APIs that are moving the needle. Developers should understand what it would mean to support an API forever. If engineering does not need to focus on keeping service A up and running, they can shift the focus to service B. This has certainly been the thinking that Google has shared as it made decisions to kill off nearly a third of its APIs.
Though not in the list above, Netflix made waves by no longer allowing new developers on its platform. The company telegraphed the move for a couple years by noting that the vast majority of its API traffic comes from the private services it makes available to its streaming partners.
Nevertheless, developers never want to see an API go away. Even if they did not pay for the service with money, they certainly pay with time to implement–and time to re-implement. API providers looking to kill off a service should be very deliberate about their approach, or they could forever alienate their technical audience.