2015: API Deprecation and Versioning Now a More Strategic Issue

Retiring an API is often an unacknowledged part of the API lifecycle. But how an API is deprecated (often referred to as ‘sunsetting an API’), is part of an API’s product life that can have a fundamental impact on future developer relationships and even the overall trustworthiness of a business’ reputation.

“From a legal perspective, an API is a contract between you as a supplier and your customers. This is defined in an API Terms of Service and Business Model Agreement,” writes Mehdi Medjaoui, API industry thought leader and founder of OAuth.io and the APIdays global conference series.

As APIs become increasingly consumed by businesses as part of their value chain, this view of an API will become more pronounced, with many businesses assessing APIs in a similar way to their current due diligence procedures around any supplier. It may be a little too early in the API economy to see real signs of this: due diligence by enterprises buying SaaS services is only starting to become documented, and due diligence procedures around choosing an API supplier are even further behind.

API Deprecation as a Measure of Trust

Developers are often frustrated by changes that introduce backward incompatibilities to an API. Such changes can break their end applications which they may be monetizing to their market customers, or that may be driving an important internal process. But there is a degree of acceptance amongst the developer community that changes to an API do occur at times, and while impactful, are begrudgingly accepted by developers who often maintain their use of a provider’s API. How well these changes are communicated and the effort that API providers put in to keeping their developers engaged and aware of upcoming breaking changes is considered one of the key signals of best practice in developer relations. Such communications will have a definite impact on the reputation that an API provider is trying to build.

But despite the growth of the API economy, it's too early to tell if a lot of developers are switching APIs based on the number of changes and backwards incompatibilities that API providers are introducing to their APIs. While changes are a source of frustration, they may not yet be a key trust signal that drives developers to look for alternatives, although that will no doubt be a growing competition factor in the near future.

But if the terms of service for using an API change, or if the API is taken away completely, developer anger surges quickly and the trust that the wider developer community places in an provider’s API can be impacted on for years to come.

The Cautionary Tale: Twitter’s API Deprecation

Twitter has been a key example of the longer term impact of destroying developer relations by shutting down an API or changing its terms of service.

In order for Twitter to accelerate growth in its early years, it offered the Twitter APITrack this API to enable an ecosystem of third-party providers to rise up and monetize the platform. Most notably successful were Twitter interfaces (‘client applications’) like Tweetdeck and Hootsuite that enabled users to view tweets in a range of graphical interfaces that for many were more user-friendly than Twitter’s own.

Similarly, they also made a full ‘firehose’ API of global tweets available to selected data analytics services like DataSift and Gnip who could then build their own businesses based on their capacity to mine such big data in realtime, a sophisticated data service that was beyond Twitter’s engineering and information resources when its focus was on building its social media business.

There is no doubt that offering these APIs helped expand awareness of Twitter and made the social media tool more accessible to a larger, global audience at an exponential rate. However, once this rapid API adoption had enabled Twitter to grow sufficiently, it turned towards controlling more of how these client applications displayed tweets, and, for many, turned off access to the API and updated the terms of service to remove the permission rights of third party developers to use the API in this way.

For many developers, this was a fundamental issue of trust that was broken. To this day, it  still impacts the level of cynicism developers have for building monetized applications on the Twitter platform and other tech giants. Others see this as a natural part of the game, pointing to the fact that Twitter bought one of those client applications, TweetDeck, and took it in-house: demonstrating that for early developers building a third-party product, the monetization endgame opportunity may be that you are bought out, and brought in.

The level of distrust, however, pervades future developer relationships. For Twitter, this meant the second half of the year has been an exercise in humble pie. ProgrammableWeb’s Editor in Chief, David Berlind, documented in October how Twitter’s founder and re-throned CEO Jack Dorsey, used this year’s developer conference to implore developers to wipe the slate clean and begin anew.

Mark Boyd is a ProgrammableWeb writer covering breaking news, API business strategies and models, open data, and smart cities.

Comments

Comments(1)

tecknoman

Good article and points to the negative side of resuse in our SOA world.  It is a lot worse internally in a business because the consumers often have more power than the provider so they can invoke change radomly without the communication and SLAs  and clear expectations for the consumers.  But the stability and simplicity of using APIs is what lets so many apps be built so quickly.  I think there needs to be some flexibility on the consumer side that they will have unexpected changes and inopportune times and that's the price of a free service or one they couldn't build themselves.