[feature] Build without OpenAPI spec

[Hybridlo]

Use case:
In my project I want to be able to generate the OpenAPI spec in development builds for internal use, but not expose it in production.

Currently this is almost impossible, since .build and .build_with functions force having openapi route(s), without the ability to remove or even limit access to that specific route with middleware.
My current solution is to use global middleware that checks every request, and limits access only to specified routes - openapi spec and swagger ui in my particular case

Alternatively there could be a way to add middlewares to apistos-generated routes, which might cover more use cases, provided such use cases exists and that would probably be a more complicated feature to implement

[rlebran]

Hi,

Thanks for the suggestion.
How do you plan on retrieving the generated OAS file if not exposing the routes ? Would you like to have a file generated somewhere, ideally at build time ?

[Walfal]

I'm also interested by this feature.
I'm would like to have the openapi in local mode, but not in production.

The idea would be to have a parameter for the visibility. So I could enable it in local, but disable for production.
Otherwise, I would use the path ".." to hide the document, but I'm not really sure for this

[Hybridlo]

Hi,

Thanks for the suggestion. How do you plan on retrieving the generated OAS file if not exposing the routes ? Would you like to have a file generated somewhere, ideally at build time ?

While that is an option, that sounds like it would be more work than what it's worth. The goal is to have access the schema during development, and for end users of the server not to have access to that schema.

There are a few ways that this could be approached. On top of my mind there's two options:

• A generate bool parameter on the build functions, which works for when people use config files to determine if the openapi spec should be avaliable. This option probably doesn't show the intent well, but covers more use-cases
• An unwrap_inner function, which would return the inner actix_web::App, while dropping the collected schema information, and the users would change between the calls using cfg attributes, something like

app
    #[cfg(debug_assertions)]
    .build(...)
    #[cfg(not(debug_assertions))]
    .unwrap_inner()

or any other way of using cfg, like feature flags
The second option is a personal preference, but covering more use cases with the first option is probably better in the long term, and it functionally works just as well