/
API4C Framework

API4C Framework

Owned by Anton Hrytsenko
Last updated: Jun 21, 2025
1 Framework | 2 Concerns | 3 Metrics | 4 Teams | 5 Tools

Framework

The API4C framework defines a way to govern APIs.

The API4C framework follows three key approaches: contract first, everything as code and shift left. The contract first approach recognizes contracts as a primary outcome and a source of truth. The everything as code approach promotes code as a primary medium. The shift left approach moves practices and tools closer to developers.

The API4C framework identifies four key concerns: circulation, consistency, continuity, and conformance. Circulation and consistency are evolutional concerns that improve the developer productivity. Continuity and conformance are operational concerns that improve the customer satisfaction.

  • The circulation aims discoverability of contracts.
    It relies on specifications to define contracts and registries to organize them.

  • The consistency aims replicability of decisions.
    It relies on guides to collect known decisions and linters to enforce them.

  • The continuity aims compatibility of changes.
    It relies on policies to define expectations and detectors to recognize changes.

  • The conformance aims correctness of implementations.
    It relies on proxies and fuzzers to identify discrepancies.

The framework is applicable for REST API (via OpenAPI), WebSocket (via AsyncAPI), GraphQL and gRPC.

Quick start

  1. Share contracts via registry for circulation.

  2. Enforce rules via linter for consistency.

  3. Control changes via detector for continuity.

  4. Verify implementations via proxy for conformance.

For example, for OpenAPI adopt Apicurio for circulation, Spectral for consistency, OpenAPI Diff for continuity and Prism for conformance.

Concerns

Circulation

Segal's law
A man with a watch knows what time it is. A man with two watches is never sure.

Problems

The split-brain problem occurs when designers neglect to collect specification in a single place. This delays development due to absent or vague specifications. The lost memories problem occurs when designers neglect to track all changes in specifications. This delays retrospectives and postmortems due to absent or fragmentary history.

Actions

Describe contracts via specifications (OpenAPI, AsyncAPI, GraphQL). Produce human-readable documentation via generators (Redocly). Document workflows via diagrams (Mermaid, ZenUML).

Store specifications and track changes via registries (Apicurio). Enforce registries to serve as single source of truth. Manage contracts as part of software catalog alongside with other pieces of software ecosystem (Backstage).

Enable seamless process that include designing, documenting, debugging and testing via platforms (Postman, Insomnia). Consider the pattern 'Design → Debug → Test'.

Consistency

Murphy’s law
If there is a wrong way to do something, then someone will do it.

Problems

The vanished decisions problem occurs when designers neglect to document their decisions. This delays design due to repetitive decision making. The protracted reviews problem occurs when designers neglect to automate checks. This delays feedback due to tedious reviews. The ignored reports problem occurs when designers neglect to tune analyzers to reduce false positives. This delays triage due to noisy reports.

Actions

Systemize patterns via style guides (Zalando, Google, Adidas) and summarize them via cheat sheets. Signify patterns level via keywords (RFC 2119).

Represent design patterns as rulesets. Apply versioning for rulesets. Validate specification for inconsistencies via design linters (Spectral, Redocly). Validate specifications for vulnerabilities vis security linters (API Scan). Integrate linters into IDE (Visual Studio Code).

Continuity

Postel's law
Be conservative in what you do, be liberal in what you accept from others.

Problems

The disrupted integrations problem occurs when designers neglect to automate compatibility checks. This increases customers disruption due to incompatible changes.

Actions

Adopt policies to define expectations on possible changes and their adoption. Focus on versioning, compatibility and adoption. For versioning, define schemas to define and triggers to update versions. For compatibility, define breaking and non-breaking changes. For adoption, define life-cycle stages, their stability and audience. Systemize policies via style guides (eBay, Atlassian).

Use detectors (OpenAPI Diff, GraphQL Inspector) to detect changes and evaluate their compatibility. Produce changelogs via detectors.

Conformance

Hyrum’s law
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

Problems

The undefined behaviors problem occurs when designers neglect to verify implementations. This increases customers disruption due to missed expectations.

Actions

Use proxies (Prism) to validate client requests and server responses using specifications. Use fuzzers (Schemathesis, Dredd) to generate synthetic requests and validate server responses using specifications.

Use mock servers (Mockoon, WireMock) to emulate contracts. Use data generators (Mockaroo) to prepare mock data.

Metrics

Goodhart's law
When a measure becomes a target, it ceases to be a good measure.

Read more about metrics in Accelerate.

The review lead time measures the time to complete peer review and accept changes. Adoption of registries reduces review lead times because it improves discoverability of contracts and traceability of changes. Adoption of style guides reduces review lead times because it remediates repetitive decision making. Further automation reduces review lead times because it reduces number of manual checks.

The conformance failure rate measures the percentage of changes that fail during the implementation validation. This reflects the implementation quality and impacts the delivery lead time.

Teams

Papert’s principle
Some of the most crucial steps in mental growth are based not simply on acquiring new skills, but on acquiring new administrative ways to use what one already knows.

Read more about teams in Team Topologies.

Create a governance team that is the platform or enabling team that collaborates with other teams that design and develop APIs. This team adopts practices and tools from industry and spreads them within the organization.

The platform embodiment of this team enables consistent evolution of practices and tools. The enabling embodiment of this team enables propagation of practices and tools to other teams.

Tools

From market:

From technology radar: