Developers love APIs. In the race to meet the demand for more applications, the global community of developers is relying on APIs to provide quick access to data and services that would otherwise need to be created from scratch. A developer writing a mobile app for a retailer can quickly display locations on a detailed map, enable payment services and allow users to share their purchasing activity through social media simply by accessing the Google Maps, Pay with Amazon, and Facebook APIs. This is the main reason for the current boom in web APIs that are fueling technology trends in mobile apps, cloud computing, social networks and the Internet of Things.
This relationship between app developers who consume the APIs and the organizations that provide the APIs can be a loving marriage that produces innovative offspring: easy-to-use, productive apps. However, like all good marriages, there has to be hard work and commitment on both sides to make it last.
Recently, there have been a number of open APIs that have shut down, leaving some API consumers stranded at the altar. Twitter introduced a new API version and more restrictive terms in order to steer more users toward its own mobile and web user interfaces. This month, ESPN announced the closure of its public API. And Netflix—whose private APIs account for double digit traffic percentages on the world wide web—is scheduled to shut down its open APIs on November 14 of this year. The reason for each closure is different. Twitter feels it needs to control the user experience in order to solve its chronic challenge of generating revenue. ESPN found that it did not have enough control over its licensable content in order to provide compelling data. Netflix simply outgrew the need for channel partners who might be found through their open API. Nonetheless, developers and in some cases entire companies were impacted by these decisions.
In order to avoid that impact and to prepare for "m-app-trimonial" bliss, here are a set of open API vows that the API consumer and API provider can consider and take:
Vows for the API Consumer
- Do you, API Consumer, understand how vital this API is to the value proposition of your application? If it is too vital, you are creating a risky dependency, and your app's value proposition may not be very strong to begin with.
- Is your partner's—the API Provider—business value proposition tied closely to the user —either controlling the user experience or directly managing the user relationship? If so, there is a risk that they will pull up stakes at some point and try to own that relationship.
- Are there any alternative providers of the same service or the same data? Fidelity is important for the strength of the marriage, but in the business world you always need a Plan B.
Vows for the API Provider
- Do you, API Provider, commit to supporting your open API in sickness and in health? If not, you need to be truthful in the terms and conditions for the API, and in your communication with prospective developers.
- Are you the authoritative source for the data you will be providing? If not, there's a good chance that regulatory policies will render your open API useless or your service will be viewed as redundant.
- Are you better than others who are providing a similar service? "Better" can mean that you have unique data, support a richer set of tasks, or provide a compelling user experience. Know what your "better" is.
Admittedly, the style of this article is tongue-in-cheek, but the points I make are serious and sincere. When it comes down to it, do I believe that sticking to these vows will help lead to a prosperous app and API marriage? I do.
About the Author
Matt McLarty (@mattmclartybc) is Vice President of the API Academy from CA Technologies. The API Academy helps companies thrive in the digital economy by providing expert guidance on strategy, architecture and design for APIs.
More articles in this series: