Fueling Digital Experiences with API Product Management
By Greg Brail
In some of my recent articles, we’ve explored what it looks like when a developer has a good experience consuming an API, and how these experiences and APIs are critical to delivering the connected digital experiences that fuel modern business.
In a nutshell, these articles explain why developers prefer experiences that make clear the API’s value proposition and make it easy to sign up to get an API key, get credentials, and start calling an API. All of this is to say, developers prefer and are more productive with APIs that are treated like products, complete with product teams that manage long-term features roadmaps and ensure their APIs appeal to both developers’ needs and the business’s goals.
When enterprises adopt this approach to APIs, the process is not always intuitive. APIs have been around for a long time, but not in their more modern, productized form. At many traditional enterprises, IT teams are more accustomed to building a one-off API to connect systems than to building an API that other developers can easily use and re-use for new purposes. Likewise, IT teams are often more accustomed to producing an API and moving on than to monitoring, supporting, and improving APIs over time.
In this article, we’ll explore some of the specific technologies, capabilities, and best practices enterprises should understand as they transition to building and managing APIs as products.
What is API product management?
API management is a set of technologies that manages the relationship between the consumers of an API and the producers of an API.
When an API product manager sets policies to control who can use APIs or reviews API traffic data to understand how and by whom APIs are being used, an API management solution is handling the job. Likewise, if a company offers a free developer version of an API that can be called 100 times per day as well as a paid version of the same API that can handle 100 million daily API calls, an API management solution is likely being used to bundle together and support the various versions, from protecting them from attackers to generating invoices.
Sophisticated companies and those that have large numbers of APIs typically use API management to manage relationships both with internal developers and external collaborators. If a company has an API that should be used only by certain teams or that just needs a sign-up mechanism to give internal developers access, for example, an API management solution is likely being used.
All of this — and more — is what API management is. In many ways, then, managing APIs like products is an exercise in identifying and deploying solutions that cover the spectrum of likely use cases.
OAuth is foundational for secure API access
OAuth is the de facto standard for access control for applications. If you use a news or shopping website that lets you sign in with your social media credentials, for example, OAuth is probably facilitating the handoffs behind the scenes.
OAuth has achieved this status in part because it lets an API product manager decouple the different parts of the user identity equation. It allows the API gateway, which is usually a proxy that’s sitting between the clients and the back ends, to actually look at access tokens and decide whether an API call should be accepted or rejected. It also allows that API gateway to be separate from the identity system that actually signs in the user — such as in the above example of one service being used to log into a different service.
Crucially, each OAuth token identifies both the developer and the application consuming the API. This can be really important. On Google Cloud’s Apigee team, for example, we’ve seen cases in which a business’s application encounters some kind of problem and starts sending thousands of requests per second to an API from phones all over the world. Without understanding exactly which application is making that request, there’s not much to be done about the situation — but if a business has an API management system that includes OAuth, IT staffers can solve the problem by sending all requests from the problematic application to another server or rejecting them entirely at the API gateway layer so they don’t bring down backend infrastructure.
Quotas protect APIs
Quotas limit the number of calls an API can accept from a given application or developer, and they can be essential to thwarting abuse. For instance, Google Cloud has quotas on its public APIs to prevent, say, a situation in which shared or stolen credentials end up used to spin up 100,000 virtual machines for bitcoin mining.
Quotas also play an important role in enabling self-service access to APIs for developers. If developers have to wait hours, days or weeks to access an API, they’re likely to look elsewhere — but when they can get up in running within minutes, barriers to adoption are much lower. Providing this sort of access is only possible if a business’s API management solution includes the ability to control the amount of traffic coming into its APIs so that a new user doesn’t overwhelm capacity.
Good quota systems let an enterprise set all kinds of quotas as well as reset them, offer different levels of service for different customers, and change them.
Don’t neglect input validation and other advanced security precautions
Security threats are a big deal, obviously. OAuth and API gateways in general are very important for security, but they operate at the highest level, e.g., whether an API call has a legitimate access token or comes from a legitimate application.
Other kinds of security threats exist and may require additional defenses. For instance, if a business amends its API to let users input some sort of JSON string, bad actors might exploit this to deliver malicious payloads or bring down the API. If there’s nothing to stop someone from inputting code that they shouldn’t, someone eventually will — which means API management should include validation capabilities to ensure APIs are only reacting to expected inputs.
As discussed above, quotas also play a role in protecting APIs, but security-minded businesses can go several steps further by exploring intelligent algorithms that identify API traffic patterns associated with malicious behavior, as well as with comprehensive analytics capabilities that not only provide visibility into API traffic but also provide insights to help API teams understand and react to threats.
Integration use cases help bridge legacy technology to the present
Use cases centered around mediation and integration between systems aren’t as focused on security or developer experiences as some other items in this article — but it remains an important part of API management.
For a variety of reasons, many companies need to build new digital experiences on top of legacy systems. The problem is, those legacy systems usually don’t present the kind of API that, for instance, a Google Home device or modern application is built to interface with.
These legacy systems may return 25kB of XML to a mobile app that really only needs 200 bytes of JSON. They may not have been designed for the Internet and their creators may have never contemplated supporting hundreds of thousands or millions of end users. Response times may be slow.
For these reasons, it can be very important for an API management system to be able to mediate and transform different technologies — to let an enterprise IT team, for example, take a SOAP application that’s been in production for 15 years, build an API on top, then use the API as interface for new digital experiences.
Monetization and other advanced features can drive optionality
A business may need additional API management tools and capabilities if it wants to do things such as charge money for access to its APIs, stand up a developer portal for API access, or apply sophisticated or customized quotas.
For example, a financial services firm may want to establish a policy that lets the foreign exchange department call the equity trading department’s APIs — but only with a vice president’s approval. Or it may want to assign a monetary value to particular API calls and then generate bills later based on usage. Not all API management solutions support these kinds of sophisticated use cases, which can be the difference between just checking an API key and actually deploying more elaborate or complicated access controls.
Deployment flexibility is increasingly important
The APIs that comprise connected experiences are increasingly anywhere and everywhere. Traditional concepts such as network perimeters are increasingly challenged or replaced by more complicated architectures that span multiple public and private clouds. All of this means that for many enterprises, it’s important to be able to not only deploy APIs anywhere but also to deploy API management capabilities anywhere.
Does the enterprise require a software-as-a-service model in which everything is run in a cloud provider’s data centers? Does it need to run the management capabilities on-premise, potentially without touching the public Internet at all? Is a hybrid option required? To choose an API management approach that will suit both current and future needs, an enterprise should consider how much deployment flexibility a given API management solution provides.
API management isn’t just one thing
As the preceding attests, API management isn’t just one thing. Managing APIs like products requires a spectrum of capabilities, some of them fairly general and some of them more refined and use case-specific. Enterprises building homespun solutions should consider whether they have the internal capabilities to address this spectrum, and likewise, enterprises investing in third-party options should consider whether basic API gateways provide the maneuverability they’ll need to react to developer needs and gain the most business leverage from their APIs.
These decisions are not IT minutiae. APIs are expressions of an enterprise’s capabilities, and like all things that represent a company and what it stands for, APIs require careful and robust management. Yes, they have a legacy as middleware and even today are focused mostly on IT users — but APIs are also how an enterprise’s most valuable data gets exposed. When exposed properly, the APIs provide business optionality — optionality to control access to digital assets, to combine old systems with new technologies, and to empower developers to experiment, innovate, and react to changing customer needs. But APIs exposed without the proper controls, developer considerations, and visibility mechanisms can be a liability that puts corporate and customer data at risk or limits the company’s options going forward.
[Looking to learn more about driving business value with APIs? Check out our ebook series “Inside the API Product Mindset.”]
