Building a New API: Public or Private?

The business strategy will determine if APIs should be open to all or just some key users.

APIs define a way for one application to interact with another. Though APIs have become the core of today’s development model, APIs should not be considered only as a tool for easy development, but more importantly, as one of the driving business factors.

Based on targeted users, APIs are categorized as public or private. Public APIs are available for everyone’s use while private APIs are restricted to employees and strategic partners of an organization. As per David Berlind, Editor-in-chief ProgrammableWeb, “the distinction between public vs. private APIs are commonly used as an ‘API language’ to communicate with API stakeholders and commonly referred to the targeted developers.

Also according to ProgrammableWeb, there are more than 13,000 public APIs, but the count is only the tip of the iceberg. Also, it is believed that the count of private APIs is much higher than that of public APIs. Successful public APIs include Facebook, Google Maps, Twitter, YouTube and Flickr, but there are examples such as LinkedInESPN, and Netflix, which have shut down their public APIs. Even Google has decided to discontinue some of its APIs such as Google Health and Reader.

In today’s competitive and fast-changing market, APIs are required for the growth and sustenance of an organization. But deciding the right API strategy for the organization’s growth is an important question. A successful API strategy covers all or some of the following factors:

  • Align the API strategy to an organization’s long-term business strategy
  • Suit most common use cases
  • Create a great developer experience
  • Monitor API usage and build proper governance/retiring strategy
  • Build a suitable monetization model
In today’s competitive and fast-changing market, APIs are required for the growth and sustenance of an organization. But deciding the right API strategy for the organization’s growth is an important question.

— Suresh Sharma, Principal Software Engineer, CA Technologies

Align the API Strategy

One of the misconceptions about APIs is that they can create a new business model for the organization; rather APIs should be considered as a tactic to support the organization’s business strategy. For example, Amazon’s success in the application economy is because their APIs are written to support their core business and designed to expose their data and functionality through service interfaces.

New technology trends such as social networking, cloud computing and the Internet of Things (IoT) have created new use cases for APIs, but that doesn’t mean that all APIs should be public. APIs can also be restricted within the organization to solve use cases such as supporting different devices/platforms for enterprise applications. Or APIs can be shared with partners to allow easier integration.

Whether an API should be public or private will depend on the organization’s business strategy and which users/developers they want to target. Many examples can be found in which organizations have changed or restricted their public APIs to correctly align to corporate strategy. ESPN has closed their public API program to better align their engineering resources with the growing demand to develop core ESPN products on their API platform.

Netflix also announced the retirement of its public API program to align with the needs of their global member base. Taking a similar approach, LinkedIn also restricted a number of APIs to be accessible only to its partners that provide the most value to their developers and business.

Hence it is very important that before starting an API program that organizations consider if the public vs. private strategy fits in with the business goals and the targeted users.

Suit Most Common Use Cases

Regardless of an API’s type, it should be designed to meet the needs of the end users. API providers should think about the kind of applications, tools or services that can be built by the API consumers. API providers themselves may not be able to predict all use cases. They should look for input from many sources, such as end users and partners, to understand the other possible use cases.

Two common aspects that need to be considered during API design are usability and security. A good API design is user-centric, but security adds complications that can reduce usability. One should consider the targeted users and use cases, and then decide the correct methods for API security. Use cases also evolve along with business goals.

In the case of private APIs, it is easier to understand the possible use cases as the targeted end users are known. But in case of public APIs, more efforts are required in understanding the targeted use cases. For instance, sharing information about how a particular API solved some of the organization’s use cases, acts as an example and can help in increasing the API adoption.

Create a Great Developer Experience

If an API is difficult to understand or implement, users will look for alternatives. There should be proper documentation and examples available for quick reference. Auto-generated documentation in the form of WSDL and WADL files can’t be used as a replacement for API documentation. In most of the cases, developers need much more information than just the method names and parameters to efficiently use the API. APIs should be stable and provide proper error handling. If an error appears, provide clear description and tips to solve the error.

For private APIs, it’s easier to collect usage information and feedback, but for public ones, collecting individual user feedback may not be possible. One of the widely used techniques to understand developer experience is to start with a prototype, share it with the targeted developer community and observe how they are trying to use the prototype. Then review what difficulties they face.

Monitor API Usage and Build Governance Strategy

APIs are like a contract describing the functionality with input, output and service-level agreements between the API provider and consumer. It’s important to keep supporting already published interfaces to ensure any existing API consumer is not affected. At the same time, it should be possible to expand API functionality based on changing business requirements. One of the common tactics is to create a new version for the API to avoid changes in existing consumer code.

Decisions about changes in an API or its removal should be based on its usage and impact. API providers should gather information on how the consumers use their API and the use cases the API solves.

API change/deprecation without providing an alternative may leave developers unhappy. In the case of private APIs, providers are aware of consumers and the usage; it is easier to understand the impact of the changes and to communicate to users in advance about the changes so that they can plan their code changes accordingly. But for public APIs, it is difficult to predict the utilization and that adds an overhead to continue support for existing APIs.

Build a Suitable Monetization Model

A competitive pricing strategy may prompt users to adopt a particular API over others. There are different techniques, such as charges per API call, per business transaction, monthly subscriptions or free APIs are adopted by organizations. Some organizations have adopted a “freemium” model such as Microsoft Bing search API in which the first 5,000 API transactions each month are free and then charges are based on additional usage.

For public APIs, the most adopted method is to charge per usage or the freemium model so that developers start using APIs with minimal or no cost, which in turn increases API adoption. Private APIs are meant for internal use so direct monetization may not be possible, but a few organizations have adopted the chargeback approach to other business unit or department consuming the API. Other ways to understand the private API value is by improved operational efficiency and reduction in development time.

Enter API Management

Both public and private APIs are important and neither is suitable for all use cases. Based on business needs or functionality, a decision needs to be made whether a particular API should be made public or private.

The challenge with API development is to minimize changes over time. Until the API is extensively used, it’s difficult to understand its problems and how its design should be. For private APIs, it is easier to understand the usage by directly working with the API consumers compared to public APIs where it’s difficult to predict all the consumers and use cases during API development. API management tools play an important role in managing the access level to keep access restrictive to a group of developers.

In most of cases, the public API started as a private one or shared with a close group of users to gain early feedback. Any API that will be exposed to the public should be designed considering the challenges associated with public APIs. The API can be managed by API management suites to restrict access to a small set of consumers. As soon as the API is ready for public use, then it can be made public without changing the API code.

API management tools help in managing the API lifecycle for both public and private APIs. Such tools also provide features for security, identity, performance, and lifecycle and developer engagement. API management tools provide insight into how organizational APIs are being consumed and by whom. And that knowledge is critical for a successful API program, private or public.

Sponsored by the Council for Technical Excellence (CTE).
 
GET THE EBOOK | API Strategy and Architecture: A Coordinated Approach >
Suresh Sharma
By Suresh Sharma | August 27, 2015

Learn how to build better apps faster.

We'll help you increase speed and quality.

See how >

Subscribe to The Blueprint

I agree to receive information related to The Modern Software Factory Hub and its newsletter, The Blueprint, as well as updates from CA Technologies and/or its partners.

Please fill out all required fields

Want to know what we are doing with your information? Read our privacy notice.

You are now subscribed to The Blueprint.