Exclude Episerver Web APIs from Swagger
Swagger, one of the worlds most popular ways to document exposed Web APIs, is a great asset to all projects that defines publicly exposed APIs. It unveils the endpoints that’s available for integration from external systems or client-side code. By default, Swashbuckle – Swagger uses ASP.NET Web API IApiExplorer to get a sense of all registered ApiControllers across your assemblies. This fact entails that even Episerver APIs – for instance from Episerver Finds “internal” Best Bet features – also are exposed. Let me show how you can avoid exposing these, to clearly communicate the capabilities of your application to your integration partners.
Define a Document Filter for Episerver
Adjusting the exposed endpoints is a fairly simple task, that only requires a single implementation along with a registration. IDocumentFilter, which is a contract provided by Swashbuckle – Swagger, enables us to intercept the process of document creation and thereby affect the output.
My implementation, shown below, simply adjusts the exposed end-points by applying a filter, to Api Controllers, based on owning assembly.
Key point, that requires adjustment according to use, is the list of Episerver assemblies to exclude Web Api’s from. For the sake of this example, I am including the assemblies from EPiServer.Framework, EPiServer.Find, EPiServer.Find.Cms, EPiServer.Find.Framework and EPiServer.CMS.Core.
Registration is fairly simple and only requires you to include a single line of code as part of your EnableSwagger delegate.
//Exclude Epi assemblies from Swagger
c.DocumentFilter(() => new EPiServerDocumentFilter());
Below image unveils that Swagger no longer exposes Episerver APIs – at least you need to trust me on that one. My pixelated filter hides confidential client information.
Enjoy Swagger. It is a terrific product to ease the communication with your front-end team and integration partners.