Lecture thumbnail 0:00 / 0:00 Still, the Swagger cannot recognize API versions.
In order to make it work, let me add some more code related to Swagger.
But before than that, make sure you have enabled URL segment API version reader
and also in the CustomControllerBase class, the API version is present as the route parameter.
OK, now in the program.cs file, you have to enable Swagger documentation for every individual API version.
In order to do so, locate the AddSwaggerGen method
because this is the place where the OpenAPI specification is being generated.
And here, hey options, I would like to generate a Swagger documentation,
I mean OpenAPI specification, that is JSON file for both versions.
First, for the first version, that is v1 and Microsoft.OpenAPI.Models.OpenAPIInfo,
this class object contains two important properties, that is title of the document,
that is, for example, cities web API and the version number.
And this is important for us. For example, let it be 1.0 for now.
So, it generates the first document for first version.
Similarly, write one more for second version number.
Like this, you need to write Swagger documentations for all the versions that you want.
Currently, we have two.
Of course, there is a possibility to make it dynamic, but it becomes more complicated.
For now, let’s try to use this one.
And also, you need to enable two individual endpoints for both versions.
I mean, Swagger.JSON for first version and second version independently.
So, go to the place where you have written, use Swagger UI.
Here, take a lambda expression that accepts options.
And in the options, you need to enable Swagger endpoint for each individual document.
I mean, for every endpoint.
By default, the URL is localhost port number.
Then the path is Swagger, followed by the version number, for example, v1 for first version,
and then Swagger.JSON. It’s the fixed name.
So, this is mapped to the first version, that is, 1.0 version.
In the same way, write one more statement for second version.
So here, the users now can access two endpoints, that is, version 1 and version 2.
When the user sends a request to this particular path,
it automatically locates the Swagger.JSON for first version, and this is for second version, of course.
So, these statements enable the endpoints for individual Swagger.JSON for every version,
and that works based on documentation that is generated for each individual version,
that is, version 1 and version 2 in this case.
This title and version numbers are included in that Swagger.JSON file.
Now run this.
Still, we are getting that error, of course.
But if you make a request to that particular URL, swagger/v1/swagger.json,
now we are getting SwaggerGeneratorException conflicting the method.
I think the same kind of error that we are getting earlier.
We are getting this error because currently the Swagger don’t know
how do you substitute with the version number in the particular URL,
and we have to inform the same.
So, after this statement called add SwaggerGen, write another statement.
Hey, builder.services.
Add versioned API explorer.
Take a lambda expression that contains a setup as parameter.
The parameter name can be anything.
It is of API explorer options.
OK, let it be named as options.
And in these options, we are writing group name format that is equal to the version number.
So, here V is the constant or literal.
So, it should be mentioned in single quotes, then followed by the version number.
The actual version number is represented as uppercase V.
For example, this can be V followed by 1 or 2, whatever it is.
But this is limited to only one digit.
But if you write one more capital V,
that means the version number can be either one-digit number or even two-digit number.
Like this, you can write one uppercase V for each digit.
For example, we have written three letters.
That means it can be up to three-digit number.
So, this is the version number now recognized by Swagger.
For example, in the URL, if someone has mentioned V1, for example,
this can be automatically decoded as version number 1,
where V is taken as literal text that is ignored.
And this 1 is taken as version number.
That will be automatically substituted as a part of the swagger.json document.
And you have to write one more, that is
options.substituteAPIVersionInURL
equal to true.
When you mention true here, then only the recognized version number,
for example, 1 is substituted here or here, whatever it is.
Now run this application.
That error has been cleared out.
Now you can see 1.0 and 2.0, two options in the drop-down list.
If you select 1.0, you can see all the endpoints of the 1.0.
Similarly, if you select 2.0,
only it contains the corresponding endpoints.
And if you can try it out,
it executes the particular version and getting the response from the same.
So this is 2.0 version and this is 1.0 version,
parallelly recognized by swagger.
First, we have to enable endpoints for each individual swagger documentation.
And this swagger.json includes with the title and version number.
And we have to supply it explicitly over here.
And we have to let the swagger to substitute
the actual version number that is mentioned here
into corresponding version path here.
So this is the code that you require to add
to make swagger to recognize API versions.
Okay, as of this particular section,
we have enabled swagger, API versions,
and also we learned about content negotiation.
So this is the fundamental knowledge that is required
to create and work with web API controllers in ASP.NET Core.
.
Play Play Play Play Play Stop Start Start Start