An API lives longer than a single release, so good API management starts well before the first breaking change, not after it.
In real design work, the chapter shows how discovery, design, versioning, deprecation, governance, and contract ownership turn an API from a one-off integration into a managed product.
In interviews and engineering discussions, it helps frame contract drift, style guides, and design review gates as mechanisms for keeping interface evolution under control.
Practical value of this chapter
Design in practice
Treat API lifecycle as a product discipline: discovery, design, versioning, and deprecation.
Decision quality
Establish governance for breaking changes and contract ownership alignment.
Interview articulation
Connect API decisions to business velocity and client-ecosystem stability.
Failure framing
Reduce contract drift through linting, style guides, and design-review gates.
Original
Telegram review
Original book review post on the Book Cube channel.
Continuous API Management, 2nd Edition
Authors: Mehdi Medjaoui, Erik Wilde, Ronnie Mitra, Mike Amundsen
Publisher: O'Reilly Media, 2nd Edition, 2021
Length: 357 pages
A summary of APIs as products: API lifecycle, contract governance, versioning, retirement, API landscapes, and Center for Enablement.
This chapter treats the API lifecycle, contract governance, API versioning, and API retirement as parts of one product system. The book is useful because it moves the conversation from individual endpoint design to change management, consumers, and interface portfolios.
Connection
Building Microservices
The API is the key contract between microservices.
API as a product
The central idea of the book is that an API should not be shipped as a side effect of implementation. It should be designed, published, supported, and retired as a product with consumers, metrics, and accountability.
Developer experience
API consumers should understand the contract quickly and make their first successful call without tribal knowledge. Time to First Call becomes a quality metric, not a vanity portal metric.
Business value
A strong API supports monetization, partnerships, or internal efficiency. It should be managed as a product with an audience, metrics, and ownership.
The Bezos Mandate
Amazon's lesson is simple: services communicate through explicit interfaces, not through informal agreements and hidden dependencies.
Ten pillars of an API product
The authors break the API product into ten areas. Read them as a maturity checklist: where the API has an explicit strategy, and where the team still relies on memory and informal agreements.
Strategy
business goals and API direction
Design
REST, GraphQL, or gRPC chosen for consumers
Documentation
OpenAPI specification, portal, and examples
Development
SDKs, clients, and integration ergonomics
Testing
contract tests
Deployment
API versions
Security
OAuth and rate limits
Monitoring
metrics, SLAs, and consumer errors
Discovery
API catalog and interface search
Change Mgmt
migration and retirement
API product lifecycle
The book describes five stages: creation, publication, value realization, maintenance, and retirement. The diagram shows that releasing an API starts the cycle rather than ending it.
API lifecycle
Create
Design and contract
Activities
- Define business requirements
- Design API (Design-First)
- Create OpenAPI specification
- Model data contracts
- Review design with stakeholders
Artifacts
Risks
- ⚠Scope creep
- ⚠Insufficient understanding of consumer needs
Continuous improvement
The key principle is managing API change velocity. The authors suggest looking at team effort, missed opportunities, and coupling to consumers.
Review
API governance deep dive
A deeper review of API governance patterns from the book.
API governance
One of the strongest parts of the book is the idea that API governance should not be policing. It is a decision-making system: who decides, which rules are automated, and where human discussion is still needed.
Decision map
Every decision in the API landscape needs three dimensions:
WHO - who decides?
Enablement center, architects, or product teams.
HOW - how is it checked?
Automatically in CI/CD or manually through review.
WHAT - what is covered?
One API, a domain group, or the whole API landscape.
Three governance models
Interface supervision
An API Guild or C4E reviews API designs. The model gives deep feedback, but it can become a queue when the organization grows.
Automated checks
Some rules move into Spectral, contract tests, and API Gateway policies. Teams get quick feedback in CI/CD instead of late manual control.
Collaborative model
Teams spread solutions through InnerSource, templates, and a shared catalog. This reduces pressure on a central group but requires mature contract ownership.
Common API governance mistakes
Uncontrolled API growth without a catalog, owners, or retirement rules.
Bureaucracy slows delivery without improving quality or predictability.
Architects set rules without seeing the real constraints of teams and API clients.
Undocumented APIs bypass the catalog, checks, and support agreements.
Automated governance tools
Spectral
OpenAPI checks
Prism
mock server
Dredd
contract tests
Kong/Apigee
API Gateway policies
API landscape: eight Vs
Once an organization has many APIs, it needs to manage a landscape rather than a single interface: styles, owners, versions, risks, and discoverability.
Variety
API styles and protocols
Vocabulary
shared domain and contract language
Volume
number of APIs and owners
Velocity
speed of safe change
Vulnerability
security risks and exposed surfaces
Visibility
discoverability in the API catalog
Versioning
versioning and compatibility strategy
Volatility
frequency of breaking changes
Center for Enablement (C4E)
Instead of the traditional Center of Excellence, the authors propose a Center for Enablement: a team that helps other teams create high-quality APIs rather than only controlling them.
Connection
Conway's Law
Organizational structure influences API architecture.
API teams and organizational structure
Business roles
- API Product Manager
- Technical Writer
- Developer Advocate
- Business Analyst
Technical roles
- API Designer / Architect
- Backend Developer
- Platform Engineer
- Security Engineer
The authors connect API architecture to Conway's law and Dunbar's number: team boundaries will eventually show up in the interface structure. An API team therefore helps not only with contract design, but also with ownership, support, and communication around change.
Applying the book in system design interviews
When to use these ideas
- Designing an API Gateway.
- API versioning and backward compatibility.
- Rate limits, quotas, and API protection.
- API catalog, documentation, and client onboarding.
Key interview questions
- How do you ship new versions without breaking clients?
- How do you announce and run API retirement?
- How do you choose REST, GraphQL, or gRPC for the consumers?
- How do you provide an SLA for a public API?
Tip: in an interview, present the API as a product. Discuss not only paths and formats, but also cataloging, owners, metrics, backward compatibility, consumer support, and retirement of old versions.
Related chapters
- Building Microservices (short summary) - API contracts between services, interface evolution, and the connection between API strategy and team boundaries.
- Inter-service communication patterns - Synchronous and asynchronous communication where API management affects reliability and change speed.
- API Gateway - Applied policy layer for authentication, rate limiting, version routing, and API observability.
- API Design Patterns (short summary) - A catalog of contract patterns and controlled API evolution in long-lived distributed systems.
- Web API Design: The Missing Link (short summary) - Resource-oriented API design practice: URI structure, links, compatibility, and quality of consumption.
- API Security Patterns - API protection and operational risk control as part of continuous API management.
- Customer-Friendly API: Product approach and design - Developer experience focus: clear contracts, predictable behavior, and low onboarding friction.