Exporting and Using the OpenAPI Specification
Exporting and Using the OpenAPI Specification
~13 Min. Lesezeit Zuletzt aktualisiert am August 8, 2026
Swagger UI from chapter 6 only shows the OpenAPI specification interactively in the browser – often the RAW specification is needed as a FILE, e.g. for Postman import or auto-generated client SDKs.
Exporting the specification via the console
docker compose exec php bin/console api:openapi:export --output var/openapi.jsonProduces a COMPLETE, static openapi.json file with ALL currently registered resources, operations, and schemas – EXACTLY the same content Swagger UI already loads in the background anyway.
YAML instead of JSON
docker compose exec php bin/console api:openapi:export --output var/openapi.yaml --yamlSOME tools (e.g. certain CI pipelines or documentation generators) prefer YAML – the --yaml flag produces content that's IDENTICAL, just formatted differently.
Importing the specification into Postman
- Copy
var/openapi.jsonout of the container:docker compose cp php:/app/var/openapi.json ./openapi.json - In Postman: "Import" → select the file.
- Postman AUTOMATICALLY generates a complete collection with ALL endpoints, including example requests.
A REAL time-saver over manually typing out curl commands from the previous chapters – especially with LARGER APIs that have many resources.
Generating client SDKs (a preview)
Tools like openapi-generator-cli can generate TYPED TypeScript clients from EXACTLY this file – an approach we DELIBERATELY do NOT choose LATER (block 9), since hand-written axios calls stay more TRACEABLE for our project's scope, but it's worth KNOWING that this option exists.
Tipp: The exported file changes WITH EVERY adjustment to #[ApiResource] – a good HABITUAL check after larger changes: re-export and diff it against the previous version to catch UNINTENDED API changes early.