Interoperability
API contracts, backward compatibility, integration standards
Interoperability is the ability of a system to exchange and use information with other systems without special effort from either side. It is achieved through API contracts (OpenAPI/Swagger, AsyncAPI, gRPC Protobuf), backward compatibility policies, and adherence to industry standards (OAuth 2.0, FHIR for healthcare, FIX for financial messaging). Versioning strategies (URI versioning /v1/, header versioning, content negotiation) give consumers time to migrate without breaking changes. Strong interoperability reduces integration costs and enables ecosystem growth — companies like Stripe and Twilio have built multi-billion dollar businesses on exceptional API interoperability.
Key Points
- Semantic Versioning (SemVer): MAJOR.MINOR.PATCH — breaking changes increment MAJOR; adding backward-compatible features increments MINOR; bug fixes increment PATCH.
- Postel's Law (robustness principle): be conservative in what you send, be liberal in what you accept — tolerate extra fields, unknown enum values, and optional fields being absent.
- Breaking API changes: removing fields, changing types, altering semantics — all require a MAJOR version bump and a deprecation window (minimum 6 months for external APIs).
- Consumer-driven contract testing (Pact) validates that a service's API meets the expectations of its actual consumers — more targeted than integration test suites.
- GraphQL enables backward-compatible schema evolution via field-level deprecation and additive-only schema changes without versioning.
- gRPC Protobuf wire compatibility: adding new fields is safe (old parsers ignore unknown fields); deleting or renumbering fields breaks backward compatibility.
- HL7 FHIR (healthcare), FIX Protocol (finance), SWIFT (banking), and OPC-UA (industrial IoT) are domain-specific interoperability standards — use them to avoid reinventing integration contracts.
- API gateways enforce contract validation at ingress, preventing malformed requests from reaching business logic and providing a single surface for versioning policy.
Real-World Example
Stripe's API has maintained backward compatibility since 2011 by pinning each customer's API version to the date of their first API call — new accounts get the latest version while existing integrations continue working unchanged. This "API versioning by date" pattern has allowed Stripe to evolve rapidly while preventing breakage for over 1 million developers using their platform.