Practise vocabulary for contract-first API development: API-first design, mock providers, schema evolution, and consumer-provider negotiation.
0 / 5 completed
1 / 5
Contract-first development means the API ___ is agreed upon before any implementation code is written.
In contract-first development, teams agree on the API contract (structure of requests and responses) before writing implementation code. This allows consumer and provider teams to work in parallel.
2 / 5
A ___ mock provider allows the consumer team to write and run their code against a simulated version of the provider during development.
A contract-driven mock (e.g., Pact's mock provider) simulates the provider based on the agreed contract interactions. The consumer tests against this mock, and the contract is then verified against the real provider.
3 / 5
Adding a new optional field to an existing API response is an example of a ___ change.
A backward-compatible change (additive change) doesn't break existing consumers because they ignore fields they don't know about. Breaking changes — removing or renaming fields, changing types — require consumer updates.
4 / 5
When a consumer needs a new field from the provider that doesn't exist yet, the appropriate approach in CDC is to ___.
CDC promotes consumer-provider collaboration: the consumer adds the new interaction to their contract, publishes it, and the provider team implements the required change to pass verification. This is explicit, traceable negotiation.
5 / 5
'Design by contract' in the Eiffel programming sense is ___ consumer-driven contract testing.
Eiffel's 'design by contract' (preconditions, postconditions, invariants in code) and consumer-driven contract testing (inter-service API contracts) are related concepts but different in scope and tooling. Distinguishing them shows precise technical vocabulary.