You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I really liked the defineRouteMeta() approach for documenting the API, but I'm curious about how it will handle the components and other global objects in the future.
Currently, it probably will looks something like this:
exportdefaultdefineNitroConfig({experimental: {openAPI: true,},openAPI: {meta: {title: 'My Awesome Project',description: 'This might become the next big thing.',version: '1.0'},components: {schemas: {Error: {type: 'object',required: ['status_code','message'],properties: {status_code: {type: 'integer',format: 'int32'},message: {type: 'string'}}}}}}})
I'm not sure if placing it all in nitro.config.ts is the best idea because it will increase the file size when new Schemas, Parameters, RequestBodies...etc, entities number grow.
One possibility could be something like this, similar to the custom error handler:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I really liked the
defineRouteMeta()
approach for documenting the API, but I'm curious about how it will handle thecomponents
and other global objects in the future.Currently, it probably will looks something like this:
I'm not sure if placing it all in
nitro.config.ts
is the best idea because it will increase the file size when new Schemas, Parameters, RequestBodies...etc, entities number grow.One possibility could be something like this, similar to the custom error handler:
This way, the configuration is isolated and treat all OpenAPI concerns. What you guys think?
Beta Was this translation helpful? Give feedback.
All reactions