Version de l'API dans une application .NET

Question

J'ai besoin d'éclaircissements sur la version de l'API dans le cadre de .Net Core.

Mon client souhaite que la version soit gérée au niveau du routeur. Comme

[Route("1/[controller]")]
public class SampleController : Controller
{
    [HttpGet("version")]
    public IActionResult GetVersion()
    {
        return Ok({"Message": "API Version 1"});
    }
}

J'y accède en utilisant, https://www.somedomain.com/api/1/sample/version

Dans IIS, je créerai une application appelée "api" (le chemin "api" dans mon URL sera pris en compte ici) sous le site web par défaut et j'y hébergerai mon code.

Quelle est la meilleure façon de procéder pour obtenir une version de l'API ?

1. Puis-je le faire ?

   [ApiVersion("1")]
   [Route("{version:apiVersion}/[controller]")]
   public class SampleController : Controller
   {
       [HttpGet("version")]
       public IActionResult GetVersion()
       {
          return Ok({"Message": "API Version 1"});
       }
   
       [HttpGet("version"), MapToApiVersion("2" )]
       public IActionResult GetVersion()
       {
           return Ok({"Message": "API Version 2"});
       }
   }

2. Est-il possible de créer une application sous une application dans IIS. Comme,

Site web par défaut - > api -> 1 -> Code sans mention de la version de l'API

Site web par défaut - > api -> 2 -> Code mis à jour sans mention de la version de l'API

3. Ou puis-je créer les versions en tant qu'application dans IIS et déployer le code sous chaque version d'application. Par exemple,

Site web par défaut - > 1 -> Code sans mention de la version de l'API

Site web par défaut - > 2 -> Code mis à jour sans mention de la version de l'API

Cela entraînera une modification de l'URL de mon API, ce que je ne préfère pas. Je souhaite toujours conserver la même URI.
J'y accède en utilisant, https://www.somedomain.com/api/1/sample/version

Veuillez me conseiller sur la meilleure approche à adopter.

Answer 1

Aquí est un référentiel populaire qui fournit un ensemble de bibliothèques permettant d'ajouter le versionnage des API aux applications ASP.NET Web API, OData with ASP.NET Web API et ASP.NET Core.

Pour les applications ASP.NET Core, vous pouvez installer le versionnement de l'API ASP.NET Core de ce dépôt en exécutant la commande suivante dans la console du gestionnaire de paquets :

Install-Package Microsoft.AspNetCore.Mvc.Versioning

Answer 2

Peut-être que la méthode d'extension Map de l'ApplicationBuilder répond à vos besoins :

app.Map( "/1", myVersion1MappingFunction)

dans la méthode Configure de Startup permet à myVersion1MappingFunction de configurer un pipeline middleware séparé :

private static void myVersion1MappingFunction( IApplicationBuilder app)
{
   // start your special middleware for version 1
   app.UseMvc( routes =>
   {
       routes.MapRoute( ... );
   }
}

Lors de l'utilisation de l'extension Map, le fragment ("/1") est supprimé de l'extension Map. HttpRequest.Path

Answer 3

Si je comprends bien, vous souhaitez utiliser l'URL Path Segment Versioning pour ASP.NET Core. Cela dit, dans vos exemples, vous allez PAS ont déployé des sites web distincts. Vous avez déployé un site web et vous faites PAS créer plusieurs applications de gestion des versions sous votre site web par défaut.

Avec le versionnage du segment du chemin d'accès à l'URL, vous disposez d'une application web qui gère toutes les routes à l'aide de la convention ApiVersion. Vous devrez maintenir le code de manière à ce qu'il puisse fournir l'ancienne fonctionnalité avec la nouvelle et gérer toutes les dépendances.

Je vous recommande de lire ce que Microsoft a à dire à ce sujet aquí et de faire une simple preuve de concept qui a du sens pour votre mise en œuvre.

J'espère que cela vous aidera à dissiper votre confusion concernant le déploiement de l'application plusieurs fois pour le versionnage.

Answer 4

Dans votre cas, la meilleure méthode serait d'utiliser le versioning au niveau du serveur web afin de pouvoir avoir différents déploiements et un dossier par version sans spécifier une version dans le routage de l'application elle-même. (votre option 2/3 ?)

Cependant, comme IIS ne fait que transmettre les requêtes à kestrel avec .net core contrairement à asp.net, vous devrez configurer le reverse proxy par URL/URL Re-write avec ARR pour les différentes versions du déploiement.

Vous auriez donc pu :

1. /Root/V1/
2. /Root/V2/
3. etc... comme vous l'expliquez.

Chaque déploiement utiliserait Kestrel avec des numéros de ports différents et IIS se réorienterait par proxy vers eux par URL.

Voici un article sur la façon de configurer ARR avec url-write. Il est écrit avec asp.net à l'esprit, mais le principe est le même :

           Reverse Proxy avec URL Rewrite v2 et Application Request Routing