Runtime filtering for generated swagger

We want to be able to apply some filtering based on querystrings. For example http://localhost/swagger/docs/v1?api=public&extensions=aws_gateway

This would retrieve the swagger doc filter to public APIs only, and would leave out internal ones. The question is whether there are extension points to do that? Several options:

1. ISwaggerProvider - this exposes GetSwagger(string rootUrl, string apiVersion) - so there is no way to fetch query string parameters.
2. Use custom SwaggerDocsHandler. There is no direct way to override this, so we’d need to have our own version of HttpConfigurationExtensions.EnableSwagger, and then construct our own swagger docs handler there. This looks ok, excepth that SwaggerDocsConfig.GetRootUrl is internal, which is needed to be passed in SwaggerEnabledConfiguration. SwaggerDocsConfig.GetApiVersions is internal as well.

Not sure which way to go.

Happy to provide a patch. a. One option is pass a HttpRequestMessage to GetSwagger method. b. The other option is to allow to pass in different SwaggerDocsHandler. c. Third option is to make GetRootUrl and GetApiVersions public from internal. Quickest change, smallest change.

[dariusdamalakas]

@djandh where do you get Request object from? There’s no way to get hold of it.

Hence my original ideas - make ISwaggerProvider aware of request (by passing request via param). I don’t feel this is great - this does not feel like a concern for swagger provider to do per-request changes to swagger.

There the 2nd option comes in - allow to customize SwaggerDocsHandler. There are 2 ways to do that - a) one is allow to pass custom docs handler implementation (slightly more code to add), b) the other is to make GetRootUrl and GetApiVersions public. This would allow to create a custom version of HttpConfigurationExtensions.EnableSwagger which would configure swagger.

I feel 2a) is the best approach, but 2b) is “OK” to some extent as well. In fact, 2b) can be done already by using reflection to access those private methods, but that his a hack and will only cause maintenance issues in the long run.

[domaindrivendev]

There’s already a method on SwaggerDocsConfig called CustomProvider. It accepts a factory method in the form of a Func that receives the default implementation and returns a custom one. This way, you can wrap the core behavior with a proxy/decorator.

I think in this case we would just need to pass the request to the factory method too so it can be passed to the custom ISwaggerProvider if desired. HttpRequest is already available when the factory method is invoked so this would be a minor change.

The only additional consideration is backward comparability as we’d be changing the signature of CustomProvider. Maybe work in an overload or else bump the major version? The latter might take longer to get out though as there’s a few other breaking changes I’d like to incorporate if possible