Original
Analysis in Telegram
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
API-as-a-Product, Ten Pillars, API Lifecycle, Governance Patterns, API Landscapes and Center for Enablement.
Original
TranslatedConnection
Building Microservices
The API is the key contract between microservices.
API as a product (API-as-a-Product)
The central idea of the book is to treat the API as a complete product, and not just a technical artifact. This means applying Design Thinking principles:
Developer Experience
Know your API consumers. Time to First Call is a key onboarding metric.
Viable Business Strategy
The API must bring business value: monetization, partnerships, internal efficiency.
The Bezos Mandate
Amazon's legendary mandate: all services communicate only through the API, no exceptions.
Ten Pillars of an API Product
The authors identify 10 key areas that need to be addressed for a healthy API product:
Strategy
Business goals and roadmap
Design
REST, GraphQL, gRPC
Documentation
OpenAPI, portal
Development
SDK, clients
Testing
Contract testing
Deployment
CI/CD, versioning
Security
OAuth, rate limits
Monitoring
Metrics, SLA
Discovery
Catalog, promotion
Change Mgmt
Deprecation, migration
API Product Life Cycle
The book defines 5 stages of the API life cycle. Hover over a stage for details or run an animation to demonstrate the full cycle:
API Lifecycle
Continuous Improvement
The key principle is management API Change Velocity. The authors identify three types of change costs: Effort Costs (team effort), Opportunity Costs (lost opportunities) and Coupling Costs (impact on consumers).
Analysis
API Governance Deep Dive
Detailed analysis of governance patterns from the book.
API Governance
The chapter on governance is one of the strongest in the book. The authors define governance not as “police control”, but as decision making system (system of decision-making).
API Decision Mapping
For each solution in the API landscape, three dimensions need to be defined:
WHO - Who decides?
Centralized (C4E, architects) or decentralized (product teams)
HOW - How is it solved?
Automatically (linters, gates) or manually (review, approval)
WHAT - What does it cover?
Individual API or the entire Landscape API of an organization
Three Governance Patterns
Interface Supervision
Human-centric model: API Guild or C4E conducts API design reviews. Provides high quality, but can become a bottleneck when scaling.
Machine-Driven
Automation of standards through Spectral linters, contract testing and API Gateway policies. Creates “paved roads” - the path of least resistance to compliance.
Collaborative
Decentralized approach: teams share patterns via InnerSource. Pull model instead of push-enforcement - best practices spread organically.
Anti-patterns Governance
Uncontrolled API growth without cataloging and deprecation
Bureaucracy slowing down development without adding value
Architects disconnected from the real needs of the teams
Undocumented APIs that bypass governance processes
Machine-Driven Governance Tools
Spectral
OpenAPI linting
Prism
Mock server
Dredd
Contract testing
Kong/Apigee
API Gateway policies
Landscapes API: Eight Vs
To manage hundreds and thousands of APIs in an organization, the authors propose the “Eight Vs” model - eight dimensions by which the maturity of the API landscape is assessed:
Variety
Variety of API styles
Vocabulary
Common language and terms
Volume
API quantity
Velocity
Rate of change
Vulnerability
Safety
Visibility
Detectability
Versioning
Version strategy
Volatility
Frequency breaking changes
Center for Enablement (C4E)
Instead of the traditional Center of Excellence, the authors propose the C4E model - a team that does not control, but helps other teams to create high-quality APIs.
Connection
Conway's Law
Organizational structure influences API architecture.
Teams API 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 refer to Conway's law And Dunbar numbers, showing how organizational boundaries are inevitably reflected in the structure of APIs. The Spotify example (squads, tribes, guilds) illustrates the scaling of API commands.
Application to System Design Interview
When to Apply Concepts
- API Gateway Design
- Versioning and backward compatibility
- Rate limiting and API security
- Developer portal and documentation
Key Interview Questions
- How to version the API?
- How to deprecate old endpoints?
- REST vs GraphQL vs gRPC?
- How to provide SLA for API?
Advice: During the interview, show your understanding of the API as a product - not only technical aspects (endpoint design), but also operational ones (monitoring, versioning, deprecation). This demonstrates senior-level thinking.