Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
publicvoidConfigure(IApplicationBuilderapp,IHostingEnvironmentenv){app.UseSwagger();app.UseSwaggerUI(c=>{c.SwaggerEndpoint("/swagger/v2/swagger.json","API v2");c.SwaggerEndpoint("/swagger/v1/swagger.json","API v1");c.DisplayOperationId();c.DisplayRequestDuration();});}privateclassApiExplorerGroupPerVersionConvention:IControllerModelConvention{publicvoidApply(ControllerModelcontroller){varcontrollerNamespace=controller.ControllerType.Namespace;// e.g. "Controllers.v1"varapiVersion=controllerNamespace?.Split('.').Last().ToLower();controller.ApiExplorer.GroupName=apiVersion;}}publicvoidConfigureServices(IServiceCollectionservices){services.AddMvc(c=>c.Conventions.Add(newApiExplorerGroupPerVersionConvention())// decorate Controllers to distinguish SwaggerDoc (v1, v2, etc.)});services.AddSwaggerGen(c=>{c.SwaggerDoc("v1",newInfo{Title="API v1",Version="v1"});c.SwaggerDoc("v2",newInfo{Title="API v2",Version="v2"});c.ExampleFilters();// Set the comments path for the Swagger JSON and UI.varxmlFile=$"{Assembly.GetExecutingAssembly().GetName().Name}.xml";varxmlPath=Path.Combine(AppContext.BaseDirectory,xmlFile);c.IncludeXmlComments(xmlPath);// Uses full schema names to avoid v1/v2/v3 schema collisions// see: https://github.com/domaindrivendev/Swashbuckle/issues/442c.CustomSchemaIds(x=>x.FullName);});}
I speak too soon, I'm having a problem calling the different versions. How do I decorate my controller to make them unique? I have something like the below but that throw an endpoints.MapControllers() error.
That is extremely clean and simple. Thanks for showing me this - I was trying to figure out a better way to do this. Using proper namespacing with ApiExplorerGroupPerVersionConvention makes a big difference.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Hello slavius, I have this implementation in an API, and without a doubt it is the simplest and cleanest thing there is. I have only identified one problem. the repetition of the endpoint code from version 1 in version 2. I have solved this by declaring my endpoints in an abstract class and inheriting from it in my controller version 1 and version 2. overwriting functionality of any of those at point if necessary and adding new ones. The problem that I keep seeing is that I will not always want all the endpoints of my version 1 to continue in version 2 of my controller. any suggestion for me
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
this seems to me more as an architectural problem. The controller should only contain domain isolated code required for it to work. All other code should be extracted to appropriate locations (repository, services, shared library) and be re-used in both controllers.
Have a look at the code from identical endpoints in v1 and v2 and try to extract as much as you can outside of the method as functions leaving only the logic. Don't forget to use interfaces for dependencies so you get good testability. Then your code should remain clean from duplicates and easy to maintain and test.
For example, if your controller queries data from a database but v2 of the same controller method uses more fields returned, you can create a function inside your repository to either accept LINQ expression with output fileds or even Where() clause or you can implement method that returns IQueryable() and materialize it inside the controller by defining SELECT columns and calling .ToList() or .ToArray().
Hi Henrick,
isn't the solution a bit overly complex?
With .Net Core 2.2 I just did:
I speak too soon, I'm having a problem calling the different versions. How do I decorate my controller to make them unique? I have something like the below but that throw an endpoints.MapControllers() error.
namespace API.Controllers.v1
{
[Route("api/v1/[controller]")]
That is extremely clean and simple. Thanks for showing me this - I was trying to figure out a better way to do this. Using proper namespacing with
ApiExplorerGroupPerVersionConvention
makes a big difference.You're welcome. I also spent some time trying to figure it out and this was the cleanest solution. Enjoy!
Hello slavius, I have this implementation in an API, and without a doubt it is the simplest and cleanest thing there is. I have only identified one problem. the repetition of the endpoint code from version 1 in version 2. I have solved this by declaring my endpoints in an abstract class and inheriting from it in my controller version 1 and version 2. overwriting functionality of any of those at point if necessary and adding new ones. The problem that I keep seeing is that I will not always want all the endpoints of my version 1 to continue in version 2 of my controller. any suggestion for me
Hi argenis96,
this seems to me more as an architectural problem. The controller should only contain domain isolated code required for it to work. All other code should be extracted to appropriate locations (repository, services, shared library) and be re-used in both controllers.
Have a look at the code from identical endpoints in v1 and v2 and try to extract as much as you can outside of the method as functions leaving only the logic. Don't forget to use interfaces for dependencies so you get good testability. Then your code should remain clean from duplicates and easy to maintain and test.
For example, if your controller queries data from a database but v2 of the same controller method uses more fields returned, you can create a function inside your repository to either accept LINQ expression with output fileds or even Where() clause or you can implement method that returns IQueryable() and materialize it inside the controller by defining SELECT columns and calling .ToList() or .ToArray().
This was awesome. And you can use whatever you want to mark the versions (attributes, namespaces, class names). I like it.
Thank you, this is clean and nice and work for me in .net core 3.0.