When I power my APIs with Swagger, I follow one of those guids and I always put the MVC injections before Swagger injections like this.
services.AddMvc();
services.AddSwaggerGen(_ => { ... });
app.UseMvc();
app.UseSwagger();
app.UseSwaggerUI(c => { ... });
A friend of mine asked why I apply that order and not handle the Swagger related lines first, before MVC. I discovered that I couldn't explain that to him nor motivate it (other than a very embarrassed well... that's the way it is...). That tells me that I should dig a bit into that matter.
Short googling revealed nothing of relevance as far I've noticed, so I'm asking here.
AddSwaggerGen is an extension method to add swagger services to the collection. To configure Swagger, you invoke the method SwaggerDoc. Passing an Info object, you can define the title, description, contact information, and more in code file Startup.
In addition to its Swagger 2.0 and OpenAPI 3.0 generator, Swashbuckle also provides an embedded version of the awesome swagger-ui that's powered by the generated Swagger JSON. This means you can complement your API with living documentation that's always in sync with the latest code.
Add and configure Swagger middlewareLaunch the app and navigate to https://localhost:<port>/swagger/v1/swagger.json . The generated document describing the endpoints appears as shown in OpenAPI specification (openapi. json). The Swagger UI can be found at https://localhost:<port>/swagger .
Swashbuckle is an open source project for generating Swagger documents for Web APIs that are built with ASP.NET Core. There are three core components: AspNetCore. SwaggerGen - provides the functionality to generate JSON Swagger documents that describe the objects, methods, return types, etc.
In this particular case, Add*
is not affected by the order they are added to the service collection.
However, depending on the implementation of the particular Add*
extension, the order may affect configuration. For example, if internally it uses the TryAdd*
extension, then only the first call registers. Subsequent calls wont add as a registration would already exist.
The general AddScoped/AddSingleton/AddTransient
calls recognizes the last call for a type as it overrides the previous registration calls for that type. When registering multiple implementations for a type, for resolving via IEnumerable<T>
then the implementations in the collection will be in the order they were registered.
Reference Dependency injection in ASP.NET Core
For the Use*
middleware the order they are added to the pipeline is important as they are invoked in the same order.
Order
The order that middleware components are added in the
Startup.Configure
method defines the order in which the middleware components are invoked on requests and the reverse order for the response. The order is critical for security, performance, and functionality.
Reference ASP.NET Core Middleware
In my experience, depending on their designed purpose, some 3rd party integrations (including swagger) that need access to the pipeline suggest adding their extensions after AddMvc
to try and avoid route conflicts.
Most security (Authentication/Authorization) and logging middleware are usually suggested to be added early in the pipeline, so they tend to come before AddMvc
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With