How APIs Become API Products
APIs have been around in various forms for a long time, so it’s natural there’s some fuzziness about how people talk about them.
To some, they’re middleware. Others say APIs are the way software talks to other software. Many think of APIs as things that big internet companies use to build ecosystems around their services or that let developers build apps that connect to lots of data and services. Yet another group sees APIs as central to modern business.
Which of these is most accurate? If you said anything but middleware, you’re at least partially on the right track.
I know, I know — in a purist sense, APIs satisfy the definition of middleware. But to think of APIs as mere integration technology is to cut off most of the value APIs can provide. They’re the mechanisms through which value is exchanged in modern business — something the entire C-suite should understand, not an IT-only concern.
Take Pitney Bowes*. Following a nearly 100-year history rooted in mailing and shipping solutions, Pitney Bowes has transformed into a provider of digital logistics and e-commerce solutions. The company uses its API platform, which includes more than 160 public APIs and 400 internal APIs, to let partners and developers leverage the company’s core services — such as location intelligence and shipping solutions — and to accelerate internal development, reducing project completion times from 18 months to only three to four months.
Or consider Walgreens*, which used APIs to open services such as prescription fulfillment to developers and now fills a prescription every second via mobile devices. Ride-sharing companies use APIs such as Google Maps for navigation. Netflix delivers content to a dizzying array of form factors and platforms via APIs. Coffee chains use APIs to power mobile ordering and loyalty programs. The examples go on.
Even so, the middleware label persists. There are many reasons. Legacy architectures, monolith apps, and traditional integration and development techniques, all of which tend to relegate APIs to their more primitive roles, are still very ingrained in many enterprises. It can be hard to see APIs as anything but middleware if middleware is all your business has ever used them for.
So, if we’re not supposed to think of APIs as middleware, how are we supposed to think of them? As that laundry list of other things in the second paragraph? To a degree, yes, but really, all of those ideas are just manifestations, some richer than others, of the same idea — that APIs are products.
What makes an API a product?
Lots of things. And as is the case with any product, whether it’s a smartphone or a sports car or a lawnmower, the success of an API product depends both on how the API is designed and how the API is marketed and maintained. Put another way, an API becomes a product when it is managed like one.
Bundling and Lifecycle Management
Whereas APIs in the legacy integration world were often one-offs, API products should be continuously monitored and iterated, with API product managers using analytics and user feedback to improve the offering. New iterations should be deployed via management tools that support dynamic changes to an existing API implementation, eliminating the need to maintain multiple versions of a service and minimizing impact to users.
As alluded above, an API product’s users are developers, whether internal or external, who create new apps and services, whether for customers, for employees, or to drive automation and efficiency.
An API product is successful when it empowers developers. With well-designed APIs, developers can agilely assemble assets from disparate sources into new products and services, like creating a tower with building blocks. This dynamic can manifest visibly in numerous ways: increased developer consumption of an API; faster development cycles; easier partner onboarding and wider ecosystem growth; etc.
Consistently-designed RESTful APIs have helped facilitate a shift from APIs that merely expose assets to APIs that are meant to be repeatedly accessed, leveraged, and consumed. A full-fledged API product advances this idea by collecting numerous API resources into bundles tailored to the needs of different developer communities.
For example, AccuWeather,* via its self-service portal, offers both an API product with up-to-the-minute weather data and an API product with daily weather data. An app that needs to constantly refresh content involves a much heavier data overhead than one that has to make only a few API calls per day, so by building differing products, AccuWeather helps developers choose the resources best suited to their needs.
This approach can enable enterprises to repackage APIs as needed without additional coding or configuration, turning the APIs into infinitely scalable assets that can be leveraged across a wide range of use cases. For full productization, API resources are typically combined with quota settings and metadata that let providers customize the product for specific developer groups.
How is API consumption changing over time? When is API response time particularly fast or slow? Which developers are using your APIs? How does API traffic vary geographically? Because APIs are the foundation from which user experiences and value exchanges spring, answering these questions can help an enterprise improve performance of services, invest in both APIs that show promise and the services those APIs support, troubleshoot problems, and generally make smarter business decisions.
Analytics are also essential to communicating the business value of an API program to non-technical audiences throughout an organization. Superficial metrics, such as the number of APIs produced, are not adequate. Beyond visualization tools, dashboards, and reports, deep visibility is required.
Access and Promotion
API products are only useful if developers adopt them, so API providers need efficient ways to engage with users. Many businesses achieve this with a developer portal.
A developer portal is a self-service site that lets developers explore and access a provider’s APIs. Whereas just a few years ago, an enterprise might have spent months exposing access for just a few developers and partners, a modern business can use a portal to get new collaborators up and running within minutes or hours.
Portals typically allow developers to register their applications, choose the API products and service levels they need, and monitor API usage. Many include knowledge centers, interactive documentation, blogs, and forums to engage the developer community. Some include monetization options that let API users participate in revenue sharing with the API provider.
APIs are an important security layer. Well-designed and managed API products should be protected by OAuth, API key verification, XML/JSON threat protection, access control, and other configurable policies. As bad actors grow more sophisticated, API protections also increasingly include machine intelligence solutions that analyze user behavior patterns to detect and block bots and other threats.
API products help businesses adapt fast
API products are so much more than middleware because they actually drive business results. An enterprise cannot address the needs of every partner or customer. API products gives these partners and customers freedom to leverage the enterprise’s assets while building out the customizations they require. This can enable a business to meaningfully expand its ecosystem, accelerate development, and improve efficiency in weeks or months, not years.
API products enable data sources to be monetized, for supply chains to be reimagined, and for applications, systems, and apps to be connected when and where they’re needed. API products aren’t just plumbing between software, in other words — they’re a way for businesses to adapt fast in the modern economy.
*Pitney Bowes, Walgreens, and AccuWeather are customers of my employer, Apigee.