Industry attributes
Other attributes
Application programming interfaces, or APIs, are used to connect different software programs to communicate with each other. Because of this, many consider APIs as systems integration technology and not software products themselves. However, these interfaces allow developers to leverage data, functions, and applications to build new products and services, and they tend to be a way for companies and businesses to express themselves in software. An API can allow businesses to expand into new contexts or adapt to changing user needs or preferences.
This has, in part, begun to change the mindset around APIs, with some companies beginning to see APIs as a chance to deliver long-term value at scale, especially as they can be evolved to meet changing customer needs. This is separate from the development of an API as a one-time project. The change in mindset has placed the API in the place of a product, to be designed like a product rather than as middleware. This has increased the ease of consumption and use, and the development of APIs can provide strategic value and future extensibility for both API developers and users.
With API as a product, the API can be monetized, often for niche functionality. An organization is able to monetize several APIs, and those are usually delivered over HTTP. Further, this has led to a new paradigm, as explored in part above, where API becomes synonymous with API-driven software as a service (SaaS), in which the API is the software, and has been seen as a natural evolution of B2B SaaS. Many API as a product providers are able to develop bespoke offerings for specific instances as well. The following are examples of this type of product:
- Stripe—offers an API for online commerce interactions to help other platforms ease overhead
- Twilio—a communication facilitation platform that offers communication benefits to companies that do not want to develop their own communication channels but integrate those channels into existing infrastructure
- Mailchimp—offers an API product solution that unifies marketing efforts across various channels
When developing an API as a product, the design of the product can matter. The design has to start with the questions of "why" and "how," which have to be defined clearly before the API is built. This includes questions regarding what problem the API can solve or help solve, how it can help companies achieve their goals, and what business needs can be met by the API. This strategy can help inform the design of the API, which can matter for end-users.
The design questions center around the vocabulary used in the development of the API, as the words and terms used can increase or decrease the learning curve and understanding for end-users. Another design consideration is the styles of the API or what protocols the API supports, such as REST or GraphQL. Also, a more natural or less natural design can be chosen, such that a user may have to change their way of approaching using an API, in comparison with an API that follows established standards or conventions. Finally, consistency should be considered, such that the API can be familiar with related products, which makes it easier for a user to switch to a new API or have consistency in experience with APIs across the offerings of a single company.
As part of designing an API as a product, a company can also turn to dedicated tools and open-source communities that work to help users design and manage APIs as a product. These include Microcks, an open-source Kubernetes-native tool for API mocking and testing tool; Apicurio, a tool to help users design API contracts collaboratively; and Red Hat 3scale API Management, designed to help ease the design and management of APIs as a product through collected feedback and active management of an API.
When designing an API, it is also important for the company offering the API as a product to enforce a consistent set of security policies and protocols across public and private APIs. This can include authentication systems, such as OAuth 2.0 or OpenID Connect, with a transport layer encryption to protect the data and control who has access to it. Further, it can include consideration of spike arrests, per-app usage quotas, and related concerns to maintain consistent API performance.
Similar to the products sold under a SaaS model, an API developed as a product has to follow a new lifecycle management protocol compared with legacy APIs. While a legacy API integration was often considered a one-off product that would be discarded and replaced as soon as the product was considered obsolete, an API developed as a product should be continuously monitored and iterated. Analytics and user feedback continually improve the API, with new iterations deployed through management tools capable of supporting dynamic changes to the existing API implementation, rather than replacing those implementations.
Because API users are developers, an API product designed to be capable of empowering developers, for example by giving them a tool capable of assembling assets from disparate sources into a new product or service, is more likely to attract customers to it. This requires, as part of an API lifecycle, that the product is consistently designed to facilitate more assets to be exposed to and capable of being retrieved by APIs, bundling these resources into the existing product, and publishing those resources to the users to meet their needs.
In order to create an API as a product, the API has to be monetized. The monetization model that a company chooses for an API is often dependent on the type of API product offering. For example, a technical API product may charge per integration or per rate of data transfer, while a commerce or payment API may charge through a transaction percentage or subscription model. As such, with the range of types of APIs, there is a near equal pluralization of monetization models.
Models for API monetization
As explored above, APIs have specific lifecycles. As a product, these lifecycles are different than those lifecycles for APIs that are intended to be replaced and tend to include the design, development, testing, management, and maintenance of the product. To help with this, there are various companies that sell API management services. These companies tend to treat the API as a product and tend to offer the following services:
- API design—this often includes the tools and templates to design, publish, and deploy APIs as well as record documentation, security policies, descriptions, usage limits, runtime capabilities, and related information.
- API gateway—this refers to API management solutions serving as a gatekeeper for APIs through the enforcement of relevant API security policies and requests and guarantees authorization and security.
- API store—often API management solutions offer users the ability to keep their APIs in a store or catalog where they can be exposed to internal or external stakeholders, so users can subscribe to APIs and obtain support from users and the community.
- API analytics—this allows users to monitor API usage, load, transaction logs, historical data, and other metrics to better inform API use and development.
Some API management services also offer cloud and on-premise hosting for an API. This hosting, along with analytics services, allows API management service providers to help API developers determine routes for iteration and services that should be included or removed from an API. Further, these services allow users to keep all of their APIs behind a single IP or domain and protect them with keys, tokens, and IP filtering. This can help secure the API without the API developer needing to develop that security infrastructure or needing to host the API services.
