An API can connect systems without being useful or approachable to its consumers. An API product goes further: it packages an API solution around a problem consumers need solved, with security, documentation, support channels, and an API team responsible for its life cycle. It may expose business capabilities externally or technical capabilities internally. section 1.3
Managing an API as a product means:
- Identify consumer problems and the value the API should provide; then design, validate, implement, document, and publish the solution. section 1.3
- Monitor use and operations, and improve the API over its lifetime. Specify quality-of-service expectations in a service-level agreement, including characteristics such as uptime and rate limits. section 1.3
- If the service is billed, state how consumption is metered and charged in a pricing plan. section 1.3
Internal and external products
An internal Permissions API can be an API product just as an external business API can. The distinction is not who may call it, but whether a team manages the packaged solution around consumer needs. In a microservices architecture, an API gateway can expose the product interface and route requests to backend services. section 1.3 section 1.4
For delivery, first map the path from customer request to production API to find delays worth automating. APIOps can then validate API definitions against governance standards and deploy product configuration through Git-based workflows. Automation reduces handoffs, but the API team still needs to understand consumers and review design decisions. section 1.4 section 1.7
Figure 1.2 An API product is a packaged API solution that provides a core problem-solving benefit to an API consumer. It has nine components, including good documentation and support channels, and an API team that oversees its life cycle.
The diagram places the consumer’s problem-solving benefit at the center of the packaged solution and shows its supporting product components. section 1.3
