This is exactly what many developers are left thinking when their dependent application is stripped away from the proverbial teat that of which their survival rested upon. You may ask, “Why? Why would a company do such thing to their loyal, er, developers?” You may feel like Scarlett O'Hara during the closing scene of “Gone with the Wind,” but truth-be-told, you're not really being abandoned.
Companies have legitimate logic behind their decisions, and besides, given the nature of the field, developers are an adaptable group of folks. When researching the reasoning behind Orange's recent decision to stop the provision of Orange API Services it became clear that Orange's predicament was not a unique one and thus it would be more appropriate to write an article without using Orange as the sole target. So let's not shed tears over our losses. Instead, let's try and learn a thing or two about why this sort of thing happens and more importantly, what it means for the third parties involved.
It's All About Business Value
The actual answer to why this sort of thing happens is most often of a fiscal rationale. That's not to say that there are not technological motives residing below the surface because, in fact, technological reasons are what directly provides the negative financial impact.
It will come as no surprise (after all we are talking about APIs) that the largest of the technological factors is the behemoth known as security. Security costs, and the bigger the company the more expensive it gets.
The largest price tag comes on an API that exposes vulnerability. Down time, restructuring of secure data, class action lawsuits and rewriting vulnerable code after a breach are all potential money pits caused by security, or rather a lack of. When Google ceased the provision of their Google Translate API in 2011 they claimed the decision was a result of “extensive abuse.” The fact that many tech giants have 15-30% of staff dedicated to the area of security is a testament to the importance of this facet. If an API demonstrates a potential for abuse then the axe it gets.
The millions or even billions of dollars in potential losses are just not worth it Aside from technological motives, it might just be more profitable to not offer a free service (go figure). If the revenue created doesn't balance the deficit caused by maintaining an API then you can't blame a company for getting rid of it.
At some point in time every company will close down an API, so there's no need to start pointing fingers now. Deprecation is a very common and legitimate reason for discontinuing an API. Twitter is currently undertaking some serious spring-cleaning and officially is retiring their Twitter REST API v1.
Another example of a large API deprecation was that of Facebook’s REST API in 2011. Facebook ported all of the API features over to their Graph API so the deprecation was the obvious progression.
Luckily most companies make sure to continue offering similar services via updated APIs. The point is that whether the API is deprecated and replaced with a new version, or being pulled off the shelf entirely, APIs will come and go and we have to be able to deal with it.
Avoiding API Catastrophe
First of all, never build an application to be entirely dependent on another parties API. This might seem improbable in certain situations, but at the very least use foresight to target potential substitutes for the main API involved. Another obvious rule of thumb is to write good code. By writing good code you will ease the pain of transitioning your application from one parties API to another.
If you're involved in the development of an API for a given company then there are certain considerations to take in order to prolong the shelf life of your product. Efficient and maintainable code is one. Good code will decrease the manpower and subsequent cost necessary to maintain the API resulting in a decreased likelihood of having to cancel provision. As mentioned before security is one of another consideration. Test, test and test again. Test your API for potential vulnerabilities from every angle possible.
So where should you go and what should you do? We'll hopefully, if you took some necessary precautions during development, you won't have to do much of anything. Or, even better yet, perhaps the development team creating the API will have tested extensively for all deficits and potential vulnerabilities, in which case the world would be a much better place.