Businesses today face many challenges to use their resources (personnel, data, and capabilities) to support their brands and connect with customers in as effective and engaging manner as possible. In many cases these challenges can be defined in two concepts: “exposure” where information and capabilities are made available to people who can use them and “consumption” where people can make use of the information and capabilities in as effortless way as possible.
API management products are industry solutions that support both of these concepts. With the proper solutions in place a business can expose data and capabilities appropriately and securely to people (both internal and external) allowing them to easily consume the APIs and build applications that use the information and processes that make your business unique.
One of the surprising things in many client conversations it is how often the same questions come up in initial discussions. Over the next few weeks, I’d like to visit some of these questions in a series of blog posts to provide basis on how we might kick start a conversation about an API strategy.
The first question I want to address is “Do you want your APIs to be public or private?” The conversation around this question involves two of the most fundamental aspects of an API, namely who are you writing the API for and what the goal for creating your API is.
Do you want your APIs to be public or private?
This question is one of the first questions that people consider and usually it is easily answered. The first point I’d like to make here is that two types of API programs are not mutually exclusive and they often go hand in hand.
In its purest form, public generally means that you want people outside your business to have access to the APIs. Usually these people will be independent developers who want to use your API to build something that they think will be valuable to consumers. Following this path can promote your brand, expand your IT capabilities beyond your IT staff, and (if you monetize your API) can offer a new revenue channel for your business. API management software is used to control secure access to your APIs and monitor and control the traffic coming in from these independent developers. There are a myriad of public APIs to consider as examples such as the one created by the movie rating site Rotten Tomatoes™ or National Public Radio’s API to get archived content in a convenient, standard way.
Private means that you intend to even more closely control who has access to your APIs and usually these people will be employees of your company. This path is used to organize and normalize access to business assets and provide a frictionless way for internal developers to get self-service access to different parts of your business (for example each line of business might share its own set of APIs.) Examples of private APIs are a little more difficult to reference because, well, they are private. However ESPN and Netflix are representative of a public API that was taken private after a period of time.
Both public and private API programs can foster innovation and provide a self-service mechanism allowing developers to gain access to the capabilities that the APIs provide. Additionally there are some other types of access along this spectrum such as APIs that are designed only for trusted partners to access allowing them to access and share data in a more streamlined way or if your business acquires another company exposing an API to them can help them get integrated into your business environment quickly and easily.
Remember, the answer to this question is not mutually exclusive. You can purse a private strategy, public strategy, both, or switch from one to another at any time. Some considerations should be made when choosing one or the other however. After establishing a public API program, deliberate consideration is advised when moving the APIs to be exclusively private. While there may be valid reasons for doing so, how you go about it will directly influence the user base you’ve built up and the applications that have been created on your public API. You’ll want to mitigate any negative impacts to the good will and brand promotion built up through the course of working with your external developers. On the other side of that coin, when working through building a private API program you should always keep in mind that someday it could be made public. Keeping this perspective, strategic and tactical decisions can be made so that any rework that will ultimately be required to expose the private API to external users is minimized.
References
“Welcome to the Rotten Tomatoes™ API” (http://developer.rottentomatoes.com)
“NPR Tech Center, API Documentation” (http://www.npr.org/api/index)
“Public API Retirement” by Chris Jason (http://espn.go.com/static/apis/devcenter/blog/read/publicretirement.html)
“Netflix Kills Off Its Public API, Takes A Few Applications Down With It” by Greg Kumparak (http://techcrunch.com/2014/11/16/netflix-api/)
