Negli scorsi due script abbiamo parlato di API versioning in ASP.NET Core, e imparato a sfruttare la libreria Asp.Versioning di .NET Foundation.

In entrambi i casi, abbiamo sfruttato come selector per la versione un parametro in query string. Tuttavia, in Asp.Versioning possiamo personalizzare questo aspetto, grazie a una serie di provider disponibili che consentono di leggere il numero di versione anche da altre sorgenti, quali un path nell'URL, l'header della richiesta, media type, o persino di scrivere i nostri provider custom.

Immaginiamo allora di voler sfruttare un path nell'URL dell'endpoint per indicare la versione desiderata, per es.

https://localhost:7133/v1/people

Non dobbiamo far altro che specificare il corrispondente version reader in fase di registrazione del servizio:

builder.Services.AddApiVersioning(options => {
    // default version non è supportato con URL segment versioning
    // options.AssumeDefaultVersionWhenUnspecified = true;
    options.ReportApiVersions = true;
    options.ApiVersionReader = new UrlSegmentApiVersionReader();
}).AddMvc();

Come si evince dal commento, usando UrlSegmentApiVersionReader il numero di versione diventa parte integrante del path, e pertanto il concetto di "versione di default" non è più supportato.

Quando specifichiamo il routing, possiamo poi indicare dove risiederà questo parametro nel path, indicando il tipo apiVersion:

[Route("v{version:apiVersion}/[controller]")]
[ApiController]
[ApiVersion("2.0")]
public class People2Controller : ControllerBase
{
  // .. altro codice qui ..
}

Questo formato funziona anche in caso di Minimal API:

myVersionedApi.MapGet("/v{version:apiVersion}/weatherforecast", 
  // ... altro codice qui ...
).HasApiVersion(1.0);