openapi: support "paths" top level object
Originally opened by @charlesvdv in https://github.com/cuelang/cue/issues/735
Is your feature request related to a problem? Please describe.
I was trying out cue to generate an openapi definition for a REST api. During my prototyping, I quickly discovered that only some top level objects are supported (version and components via the definitions concept). If the openapi is only used to perform schema validation (like the cue-gen example), this is fine. However, I believe most use-cases are using the openapi spec to specify full-blown REST api.
Describe the solution you'd like
The openapi generator should support other openapi top-level objects like the paths objects. Something like this:
package openapi
$version: "v1beta2"
#SomeDef: {
foo: string
}
paths: {
"/foo": {
get: {
responses: {
"200": {
content: {
"application/json": #SomeDef
}
}
}
}
}
}
Note: I am cue novice so my idea/approach may be completely off...
Original reply by @mpvl in https://github.com/cuelang/cue/issues/735#issuecomment-774619647
That's definitely something that's on the table and an appropriate use. We have been focusing on getting the language down first. We have taken these kind of use cases in consideration for these design efforts.
Original reply by @charlesvdv in https://github.com/cuelang/cue/issues/735#issuecomment-774642899
Great to hear! If ever you need some help on the openapi generator, I would be happy to help! I would just need to have a rough sketch of what the clue files would look like because I know my example is not a valid clue file and I don't have a clear view on all the clue language constructs/features yet.
At the moment, paths is a disallowed top level object when exporting to openapi. Would a good first step be to simply allow that top level object to be used?
I'm interested in helping with this issue, but I'm new to Cue. I'm unsure if there's a larger requirement to fulfill this issue, such as defining a schema for paths.