Engineering · 18 June 2026 · 9 min read
Generating REST, OpenAPI 3.2 and GraphQL from the same registry
A walkthrough of how the published schema registry produces a consistent query language across REST, JSON:API and GraphQL, with an OpenAPI document that can never fall behind.
Platform team · API engineering
One query language
Filtering, sorting, sparse fieldsets, relation includes and cursor pagination are defined once in the query layer, so every surface answers the same questions in the same way. A filter learned on REST works unchanged in JSON:API and GraphQL.
Documentation as a build artifact
The OpenAPI 3.2 document is regenerated from the registry on every publication, which means the contract is a projection of the schema rather than a file somebody remembers to update. Validation rules travel with it: bounds, patterns, enumerations and required flags appear in the schema objects.
GraphQL without a second model
The same definitions produce SDL, input types for structured fields and unions for dynamic zones. Because resolvers read the registry, a newly published model is queryable immediately.