🚀 Feature: Dynamically disable options (try-it / authorize buttons) on Swagger page in API Catalog

🔖 Feature description

There are some APIs in the catalog that need to disable the try-it and the authorize buttons in the API Swagger page. I see this feature as a way to pass in the definitions as well as customizable plugins / options to the Swagger page (options and plugins used interchangeably going forward when talking about the SwaggerUI).

This would allow developers to send in options for APIs and have the Swagger page apply them. Note that it would be up to the developers passing in the options to correctly format options, but then it would allow for any of the Swagger UI options to be configurable based on the options passed. It should not affect APIs without the custom options, so it would only be an add on for APIs that require custom options.

🎤 Context

Some APIs in the catalog need to dynamically disable some of the Swagger configurable options via a plugin, specifically disabling the try-it button and the Authorize button. The Try-it button setups a test call and provides a sample response in the UI, and the Authorize button creates a sample authorization token for users to use when calling certain APIs.

Further extending the Swagger page to accept options / plugins for would allow for further extensibility and control over what APIs show. By making the Swagger page take options, any other customizable aspect of the Swagger UI would be configurable now at an API level.

✌️ Possible Implementation

The Swagger UI will need to be passed plugin options in order to customize it:

<SwaggerUI spec={def} url="" plugins={plugins} deepLinking />

where the plugins are passed in through the props as seen here.

The plugins will also need to be propagated through this file.

Additionally, the options will need to be set and retrieved prior to being sent to the Swagger page, and I would imagine that having a predefined spec attribute would be a good way of doing this, and will have to be set prior to here.

Though I have not have a lot of time to really figure out how this might look, I would imagine that an API Processor could look for an Entity’s spec.swaggerPlugins (or something of that sort) and transform it into what the SwaggerUI could process. Then, in addition to passing the definition to the SwaggerUI, it could also pass the swaggerPlugins.

By propagating the options from an API, the Swagger page can dynamically render the Swagger pages differently for different APIs. It is important to make sure that the APIs without any options are not affected, but by processing the Entity’s options prior to passing the options to the SwaggerUI element, there should not be any negative effect on APIs that don’t pass options.

👀 Have you spent some time to check if this feature request has been raised before?

• I checked and didn’t find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

Yes I am willing to submit a PR!

[Rugvip]

@whitemanthedj kind of, you could also add some customization points that makes it possible for users of the API docs plugin to customize the logic. That way you may not need to change code in this repo, but your own repo.

[whitemanthedj]

If I understand correctly, then that will lose the generic ability for any of the Swagger plugins. If apis need additional plugins in the future that I don’t codify now for the swagger page, then they would have to update this repo, is that what you meant?