Beat the risks of managing public, private APIs

Many businesses today use both public and private application program interfaces (APIs), but their development and management strategies for each may be too similar. Those who fail to craft different approaches for public and private APIs likely will encounter data security issues, fewer public cloud cost advantages and poor data flow between environments, according to Mark O'Neill, vice president of innovation at Axway, a data flow and API management software and services provider.

O'Neill lays out the differences between public and private API strategies, best practices for creating effective approaches for each and how to structure an API strategy team in this Q&A.

"It's important to take data residency into account in an API strategy," O'Neill said in a recent interview. One can liken the needs for separate API management strategies for both private and public clouds to the security management in hybrid cloud environments, where all applications and data no longer live safely behind an internal data center firewall.

Also similar are the separate goals for public and private offerings. Usually, private APIs are for internal use and public APIs are a way to extend the reach of a business' applications to other users, as well as to build new user and customer pipelines. "It's important that organizations determine audience before putting in place a public or private API strategy," O'Neill said.

What are key differences between public and private APIs?

O'Neill: Private APIs are intended for a closed user group, such as a group of suppliers in the automotive industry, and the identity of each developer is already known.

Public APIs include a developer portal to engage [outside] developers to use the APIs. [They're used when] the organization wants to maximize the usage of the APIs.

What is the difference between a public API, also known as an open API, strategy and a private API strategy?

O'Neill: For public APIs, the goal often is to reach many external developers. Daniel Jacobson [Netflix API director of engineering and author of APIs: A Strategy Guide] refers to these developers as LSUDs (large sets of unknown developers). A good example of this is Uber opening up an API to make Uber ridesharing directly available through other platforms, such as restaurant reservation apps or hotel booking sites, thereby encouraging users to leverage the service more frequently.

Not all business goals are tied to increased exposure. For instance, some industries, such as healthcare, face heavy regulation and privacy requirements, meaning an open API may not be ideal from an auditing and management perspective.

For private APIs, again using Jacobson's terminology, a more targeted approach to SSKDs (small sets of known developers), such as distinct partners, makes sense.

Are there other considerations for businesses when determining which approach is best for them?

O'Neill: First and foremost, after determining the goal of an API program, businesses should evaluate the dynamics of the industry they are in and their relevant target audience. It is also important to take into account the amount of resources a company can invest in its API because a public API will require more management on the back end.

What is an example of a model for hybrid API?

O'Neill: We see organizations taking a two-stage model, whereby they have an external API gateway on a public cloud service, with a backhaul link to their on-premises systems. At the external (public) side, authentication and API firewalling is applied. Connections to internal systems are only initiated from the internal (private cloud) stage, removing the security risk of opening up a direct connection from the public cloud to internal systems. This approach has a cost advantage because the outer (public cloud) layer can take advantage of elasticity.

What are the challenges in developing APIs in each situation?

O'Neill: Security is the top challenge for developing both types of APIs. We are seeing more and more attacks on APIs. Attackers realize that APIs are often the soft underbelly of mobile apps, in particular. We've already seen various API security breaches, from Snapchat to Moonpig.

Different security policies may be used in each situation -- this includes OAuth, OpenID Connect and other standards. It can be challenging to support these security standards in APIs.

What are the metrics of success for each strategy?

As APIs become widely adopted, they become revenue centers of their own, resulting in organizations wishing to charge for API usage.

O'Neill: With APIs, it's important to realize that determining ROI is not a simple calculation. Everything from pricing, which can often be free, to the resources it takes to maintain, should be weighed. As APIs become widely adopted, they become revenue centers of their own, resulting in organizations wishing to charge for API usage.

It's also vital that organizations tie success to the business goals they determine. For example, this can mean things like entering new industries, getting in front of different consumers, streamlining partner collaboration and more. It's easy to see how attaching a strict dollar amount to the success of an API is not only difficult but also unlikely to provide a complete picture.

How has increased use of APIs changed IT and software development teams?

O'Neill: API strategy is following a path similar to that of the early days of the Web. The first corporate websites came out of IT departments, but when requirements matured to include ecommerce, a dedicated Web team was put in place. Similarly, with APIs the first efforts often came out of IT, or were ad-hoc APIs to support a particular mobile app. But now, we increasingly see dedicated digital strategy teams at organizations. Their responsibilities include API strategy, as part of overall digital engagement encompassing mobile, developer engagement (e.g., hackathons) and Cloud.

• The digital team includes API designers, who craft APIs based on consumers -- usually choosing to adopt standards such as Swagger.
• Developers have an important role to play, to test APIs and also to provide feedback. The team usually comes under the CIO, although in some cases we see a chief digital officer role.
• The DevOps team is one of the stakeholders in API strategy, because it is important that an API management platform is chosen that provides DevOps capabilities for API deployment.