Support creation of multiple openapi documents
Description
Smallrye OpenAPI supports creation of multiple openapi documents using profiles.
This is useful in e.g. following scenarios:
- Seperation by external and internal description
- Seperation by domain
- Seperation by api version
A profile is declared by defining an extension on the resource class or method that should be part of a profile:
@Extension(name = "x-smallrye-profile-external", value = "")
All created openapi schemas should be viewable in swagger-ui.
FTR, this was the PR for smallrye-openapi introducing profile support. https://github.com/smallrye/smallrye-open-api/pull/967
Implementation ideas
No response
/cc @EricWittmann, @MikeEdgar, @phillip-kruger
@Postremus are you working on implementing this ?
yep, will take a look. Might take a bit though for me to get started on this one.
I am removing myself as asignee from this issue. TBH, I noticed everytime I tried to start that I am just not interested enough in this topic to do this in my free time. :)
(although yes, I want this feature for at-work stuff.)
Ah, just came to here from google, as I was looking to see if Quarkus had support for this.
I hope somebody will pick up this feature request eventually.
@EricWittmann, @MikeEdgar, @phillip-kruger: Do you have an idea what would need to be changed to make this work with Quarkus? I see the @Extension annotation is available, but I'm not sure what exactly is missing. Can you give us a hint?
I have no idea. Maybe @MikeEdgar knows? I suspect we would need some work in the extension to scan more than once ? Or have a runtime filter that filter things out/in based on the @extension
@phillip-kruger AFAIK:
- Allowing multiple configurations, one for each openapi document that should be generated.
- Expand the configuration to have an optional includeProfile and excludeProfile list.
- For each configurations, scan everything.
- Allow swagger-ui to display these additional generated documents
An @extension and Runtime Filter itself is not enough, since you can have multiple documents, and multiple profiles in one application.
Yes, we would need to scan multiple times, apply filters to each document at runtime (do filters apply to all or just one OpenAPI result?), etc.
Another important thing to work out is how the multiple OpenAPI documents are hosted. Currently there is only /q/openapi, but each of the documents would require its own endpoint presumably.0
This would probably require some map-based configurations to allow configs, filters, etc. to apply only to single OpenAPI documents where the key is the profile name that is already supported by Smallrye OpenAPI.
I want this feature - so I guess I will just implement it myself :)