API versioning with ASP.NET MVC Core and NSwag


We support versioning in theory, but we've never really left v1.0

If this is a quote that resonates with you, read on.

Our team added our first v2.0 endpoint in one of our products by doing the following:

  • Removing [ApiVersionNeutral] on the endpoints that we didn't want versioned (as opposed to being available on any version of the API).

  • Configuring ASP.NET to assume neutral if unspecified:

    services.AddApiVersioning(
    o =>
    {
    o.UseApiBehavior = true;
    o.DefaultApiVersion = ApiVersion.Neutral;
    o.AssumeDefaultVersionWhenUnspecified = true;
  • Removing our [ApiVersion("1.0")] on our base controllers

  • Decorating our old methods with [ApiVersion("1.0")]

  • Decorating our new methods with [ApiVersion("2.0")]

It took some trial and error, as we presumed that we could just add [ApiVersion("2.0")] on our new stuff and be done with it. This made NSwag registering the endpoints multiple times, however, as did decorating an inherited controller with [ApiVersionNeutral]

The .AddApiVersioning with the DefaultApiVersion did not seem to upset NSwag, but did allow us to presume that endpoints without an explicit version was, in fact, version-less/static.


Comments

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Unit testing your Azure functions - part 2: Queues and Blobs

Testing WCF services with user credentials and binary endpoints