OpenAPIspec
summary
Claims that OpenAPI becomes a working contract: teams use it to prototype, mock and test before code exists, not just to auto-generate reference. Tooling examples include Prism mock server for interactive sandboxes and Dredd for request/response tests. Companies run contract testing SDKs in CI so mismatches fail before merge. Public specs attract real feedback (one example shows ~440 contributors), projects report hundreds of monthly OpenAPI users and docs with thousands of weekly views, and teams integrate linting and style checks into pipelines.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:04Single source of truth
- 2:30OpenAPI specification basics
- 4:19Beyond API reference docs
- 5:45Bridging silos with specs
- 7:28Collaboration and standardization
- 8:54Developer experience importance
- 10:21Design-first approach benefits
- 11:26Mocking and prototyping
- 13:33Testing and validation
- 16:26Feedback loops with specs
- 17:51Advocating for OpenAPI
- 19:19Future of API documentation
related talks
47mContract-Driven API Development with OpenAPI Specification
45mOpenAPI for Web Developers
19mSecure and accelerate APIs' lifecycle with the OpenAPI specification
50mContract-Driven Development
30mOne Spec to Rule them all - OpenAPI in Action
31mOpenAPIs are everywhere
43mWhy You Should Be Doing Contract-First Development
25mThe Life Changing Magic of Becoming API First