.NET Core WebAPI version API de secours en cas de version mineure manquante

Ceci n'est intrinsèquement pas pris en charge par défaut. Les versions flottantes, les plages, etc. sont contraires aux principes de la gestion des versions d'API. Une version d'API n'implique pas et ne peut pas impliquer de compatibilité descendante. À moins que vous ne contrôliez les deux côtés dans un système fermé, supposer qu'un client peut gérer n'importe quel changement de contrat, même si vous n'ajoutez qu'un seul nouveau membre, est une erreur. En fin de compte, si un client demande 1 / 1.0, c'est ce qu'il devrait obtenir ou le serveur devrait dire que ce n'est pas pris en charge.

Mis à part mon opinion, certaines personnes veulent toujours ce type de comportement. Ce n'est pas particulièrement simple, mais vous devriez être en mesure d'atteindre votre objectif en utilisant un IApiVersionRoutePolicy ou custom endpoint matcher - cela dépend du style de routage que vous utilisez.

Si vous utilisez toujours le ancien routage, cela peut être le plus simple car vous créez simplement une nouvelle stratégie ou étendez la DefaultApiVersionRoutePolicy existante en remplaçant OnSingleMatch et enregistrez-le dans la configuration de votre service. Vous saurez que c'est le scénario que vous recherchez car la version de l'API entrante n'aura pas la version mineure. Vous avez raison de dire que 1 et 1.0 équivaudront à la même chose, mais la version mineure n'est pas fusionnée; par conséquent, ApiVersion.MinorVersion sera null dans ce scénario.

Si vous utilisez Endpoint Routing , vous ' ll faudra remplacer ApiVersionMatcherPolicy . Ce qui suit devrait être proche de ce que vous voulez réaliser:

[ApiController]
[ApiVersion( "2.0" )]
[ApiVersion( "2.1" )]
[ApiVersion( "2.2" )]
[Route( "api/values" )]
public class Values2Controller : ControllerBase
{
    [HttpGet]
    public string Get( ApiVersion apiVersion ) =>
        $"Controller = {GetType().Name}\nVersion = {apiVersion}";

    [HttpGet]
    [MapToApiVersion( "2.1" )]
    public string Get2_1( ApiVersion apiVersion ) =>
        $"Controller = {GetType().Name}\nVersion = {apiVersion}";

    [HttpGet]
    [MapToApiVersion( "2.2" )]
    public string Get2_2( ApiVersion apiVersion ) =>
        $"Controller = {GetType().Name}\nVersion = {apiVersion}";
}

Ensuite, vous devrez mettre à jour la configuration de votre service comme ceci:

// IMPORTANT: must be configured after AddApiVersioning
services.Remove( services.Single( s => s.ImplementationType == typeof( ApiVersionMatcherPolicy ) ) );
services.TryAddEnumerable( ServiceDescriptor.Singleton<MatcherPolicy, MinorApiVersionMatcherPolicy>() );

Eh bien, le mérite d'avoir répondu à la question revient à @Chris Martinez, d'un autre côté, je pourrais trouver un autre moyen de résoudre mon problème: J'ai notamment créé une extension pour RouteAttribute , implémentant IActionConstraintFactory:

[ApiVersion("1")]
[ApiVersion("1.1")]
[Route("collect", "1", "1.1")]
public class ValueControllerV11 : Controller
{
    [HttpRequestPriority]
    public String Collect()
    {
        return "Version 1.1";
    }
}

Où le IActionContraint ressemble au suivant:

    public class ApiVersionHeaderConstraint : IActionConstraint
{
    private const bool AllowRouteToBeHit = true;
    private const bool NotAllowRouteToBeHit = false;

    private readonly string[] _allowedApiVersions;

    public ApiVersionHeaderConstraint(params string[] allowedApiVersions)
    {
        _allowedApiVersions = allowedApiVersions;
    }

    public int Order => 0;

    public bool Accept(ActionConstraintContext context)
    {
        var requestApiVersion = GetApiVersionFromRequest(context);

        if (_allowedApiVersions.Contains(requestApiVersion))
        {
            return AllowRouteToBeHit;
        }

        return NotAllowRouteToBeHit;
    }

    private static string GetApiVersionFromRequest(ActionConstraintContext context)
    {
        return context.RouteContext.HttpContext.Request.GetTypedHeaders().Headers[CollectApiVersion.HeaderKey];
    }
}

Ensuite, je peux utiliser ensemble ApiVersionAttribute et mon RouteWithVersionAttribute personnalisé, comme suit:

public class RouteWithVersionAttribute : RouteAttribute, IActionConstraintFactory
{
    private readonly IActionConstraint _constraint;

    public bool IsReusable => true;

    public RouteWithVersionAttribute(string template, params string[] apiVersions) : base(template)
    {
        Order = -10; //Minus value means that the api-version specific route to be processed before other routes
        _constraint = new ApiVersionHeaderConstraint(apiVersions);
    }

    public IActionConstraint CreateInstance(IServiceProvider services)
    {
        return _constraint;
    }
}

Cheers !

Qu'en est-il de l'option CurrentImplementationApiVersionSelector , lors de l'enregistrement du service? voir ici: https://github.com/microsoft/aspnet -api-versioning / wiki / API-Version-Selector

Le CurrentImplementationApiVersionSelector sélectionne la version d'API maximale disponible qui n'a pas de statut de version. Si aucune correspondance n'est trouvée, il revient à la DefaultApiVersion configurée. Par exemple, si les versions "1.0", "2.0" et "3.0-Alpha" sont disponibles, alors "2.0" sera sélectionné car il s'agit de la version d'API la plus élevée, implémentée ou publiée.

services.AddApiVersioning(
    options => options.ApiVersionSelector =
        new CurrentImplementationApiVersionSelector( options ) );