API Platform & Lifecycle · Contract-First Design
Mock Servers and Prototyping
Let consumers build against the contract before the backend exists.
Mock servers generated from specs (Prism, Microcks, Mockoon) return example or schema-generated responses and validate incoming requests against the contract. Use them for early consumer feedback, frontend development, partner sandboxes and contract tests. Prism's validation proxy mode also checks a real implementation's traffic against the spec.
Mocking tools
| Tool | Strength |
|---|---|
| Prism | OpenAPI mocks + validation proxy, CLI-friendly |
| Microcks | OpenAPI/AsyncAPI/gRPC mocks and contract testing, Kubernetes-native |
| WireMock | Programmable stubs for tests (fault injection) |
| MSW | Browser/Node mocks for frontend tests |
# Static/dynamic mocks from the spec
npx @stoplight/prism-cli mock openapi.yaml # http://127.0.0.1:4010
curl -H "Prefer: example=paid" http://127.0.0.1:4010/orders/ord_01J9ZK6R3B
# Validation proxy in front of a real backend: reports contract violations
npx @stoplight/prism-cli proxy openapi.yaml http://localhost:8000 --errors
Common pitfalls
- Mocks that drift from the real implementation (regenerate from the spec).
- Only happy-path examples in mocks.
- Frontend teams relying on mock behavior the real API won't have.
Key points
- Mocks from the spec
- Validation proxy catches drift
- Include error examples
Further reading: Prism documentation
Practice questions
What does Prism's proxy mode do?
Answer
It forwards requests to the real API and validates both requests and responses against the OpenAPI spec, reporting contract violations.
Why include error responses in mock examples?
Answer
Consumers must implement error handling (404, 422, 429) early; happy-path-only mocks hide those paths until production.
Open in the app to mark lessons complete, take notes and track your progress.