Comparaison détaillée de plusieurs versions de WebApi dans ASP.Net Core (photo)

Cet article présente principalement la comparaison de plusieurs contrôles de version d'ASP.Net Core WebApi. L'éditeur pense que c'est plutôt bon. Maintenant, je vais le partager avec vous et vous donner une référence. Suivons l'éditeur pour y jeter un œil

1. Avantages du contrôle de version :

(1) Il permet de lancer des fonctions en temps opportun manière et ne perturbera pas les systèmes existants.

(2) Cela peut également aider à fournir des fonctionnalités supplémentaires à des clients sélectionnés.

Le contrôle de version de l'API peut être contrôlé de différentes manières, comme suit :

(1) Ajouter la version dans l'URL ou en tant que paramètre de chaîne de requête,

(2) Par en-têtes personnalisés et en acceptant les en-têtes

Dans cet article, voyons comment prendre en charge plusieurs versions de l'API Web ASP.NET Core.

1. Créez un projet webapi principal asp.net et référencez le package NuGet : Install-Package Microsoft.AspNetCore.Mvc.Versioning -Version 2.0.0

Le projet et le package d'installation sont prêts, nous devons alors ajouter le code suivant à la méthode ConfigureServices dans Startup.cs :

Comme vous pouvez le voir, 3 options différentes sont configurées.

• ReportAPIVersions : ceci est facultatif. Cependant, lorsqu'elle est définie sur true, l'API renvoie les informations sur la version prise en charge dans l'en-tête de réponse.

• AssumeDefaultVersionWhenUnspecified : Cette option sera utilisée pour les requêtes qui ne fournissent pas de version. Par défaut, la version supposée de l'API est 1.0.

• DefaultApiVersion : Cette option permet de spécifier la version de l'API par défaut à utiliser lorsqu'aucune version n'est spécifiée dans la requête. Ce sera par défaut la version 1.0.

Voici toutes les configurations et réglages. Nous allons maintenant voir les différentes manières d’accéder aux versions API.

2. Implémentez le contrôle de version via QueryString

Ouvrez notre contrôleur et ajoutez-y la fonctionnalité ApiVersion, comme indiqué dans le code suivant :

Le code ci-dessus est celui de la version 1.0. Vous pouvez également créer une autre classe de contrôleur portant le même nom dans un espace de noms différent et définir la version de l'API sur la version 2.0. Comme le montre l'image ci-dessous :

C'est tout. Allez maintenant dans le navigateur et accédez au contrôleur. Vous devriez voir la sortie du contrôleur API version 1.0 car elle est définie par défaut. Ajoutez maintenant api-version=2 dans l'URL et vous devriez voir la sortie du contrôleur API version 2.0.

2 Implémenté via le segment de chemin d'URL :

• api/v1/values

• api/v2/values

Toujours projet ci-dessus, il vous suffit d'ajouter le code suivant aux contrôleurs v1 et v2. Comme indiqué ci-dessous :

De même, vous devez mettre à jour les paramètres de routage vers tous les emplacements applicables. Avec ce changement, un numéro de version est toujours requis lors de l'accès à l'interface API. Vous pouvez accéder à la version 1.0 via api/v1/values ​​​​et à la version 2.0 via api/v2/values ​​​​en modifiant le numéro de version dans l'URL. Simple et semble plus propre.

Les résultats des tests sont les suivants :

3. En-têtes

Dans les deux méthodes ci-dessus, l'URL doit être modifiée pour prendre en charge le contrôle de version. Toutefois, si vous souhaitez que l'URL de l'API reste propre, les informations sur la version de l'API peuvent également être transmises en ajoutant un en-tête HTTP. Pour que cela fonctionne, vous devez configurer les options d'ApiVersionReader. Le code est le suivant :

La ligne en surbrillance nous indique que l'en-tête "api-version" est désormais l'emplacement attendu pour le numéro de version de l'API. Assurez-vous que les propriétés de l'itinéraire ne contiennent pas de détails de version. Alors testez-le et voici le résultat :

Lorsque vous fournissez 2.0 comme valeur à "version api", il appellera le contrôleur de version 2.0 et renverra la sortie.

Simple et facile à mettre en place. Cependant, la méthode de paramètre de chaîne de requête pour la gestion des versions ne fonctionnera plus. Une fois l'en-tête défini, les paramètres de chaîne de requête ne peuvent pas être spécifiés. Si vous souhaitez prendre en charge les deux cas, utilisez QueryStringOrHeaderApiVersionReader au lieu de HeaderApiVersionReader. Le code est le suivant :

Par conséquent, les paramètres de chaîne de requête et les en-têtes sont désormais pris en charge. Le nom du paramètre de chaîne de requête par défaut est api-version, vous pouvez donc laisser le constructeur vide, mais si un nom différent est requis, vous devez le fournir. Vous pouvez également utiliser des noms différents pour les paramètres et les en-têtes de chaîne de requête. N'oubliez pas que nous définissons également ReportApiVersions sur true, ce qui renvoie les informations de version dans l'en-tête de réponse. Voir photo ci-dessous.

Maintenant, examinons quelques options supplémentaires.

Utilisation du paramètre MapToApiVersion :

L'attribut MapToApiVersion permet de mapper une seule opération d'API à n'importe quelle version. En d’autres termes, un seul contrôleur prenant en charge plusieurs versions. Les contrôleurs ne peuvent disposer que de méthodes d'action API prises en charge par la version 3. Dans ce cas, vous pouvez utiliser MapToApiVersion. Jetez un œil au code ci-dessous.

La signification du code ci-dessus est : chaîne publique Get() Cette méthode n'est prise en charge que dans la version 1.0, et la méthode chaîne publique Getv3() n'est prise en charge que dans la version 3.0.

Il y a des photos et des images réelles, c'est très flexible, j'aime beaucoup.

Utilisation du paramètre Obsolète :

Lors de la prise en charge de plusieurs versions d'API, certaines versions finiront par devenir obsolètes au fil du temps. Pour marquer une ou plusieurs versions d'API comme obsolètes, décorez simplement votre contrôleur avec Obsolète. Cela ne signifie pas que les versions API ne sont pas prises en charge. Vous pouvez toujours appeler cette version. Il s'agit simplement d'un moyen de faire savoir aux utilisateurs de l'API appelant que les versions suivantes seront obsolètes à l'avenir.

Le paramètre Obsolète sur TRUE ci-dessus signifie que la version 1.0 sera obsolète à l'avenir. Lorsque vous accédez à notre interface API, vous pouvez voir les informations suivantes dans l'en-tête de réponse, comme le montre la figure ci-dessous :

Utilisation de la fonctionnalité ApiVersionNeutral :

ApiVersionNeutral Définition de la fonctionnalité Cette API ne prend plus en charge le versionnage. Ceci est utile pour les API qui se comportent exactement de la même manière, qu'elles prennent en charge la gestion des versions d'API ou pour les API héritées qui ne prennent pas en charge la gestion des versions d'API. Par conséquent, vous pouvez ajouter la propriété ApiVersionNeutral pour quitter le contrôle de version.

Obtenir des informations sur la version (Version Information)

Si vous souhaitez savoir à quelle version du client vous accédez, vous pouvez implémenter cette fonction via ce qui suit code :

Pour résumer, disposer de plusieurs versions de l'API peut aider à déployer des fonctionnalités améliorées de manière efficace tout en facilitant le suivi des modifications. Dans cet article, nous avons vu comment ajouter la prise en charge de plusieurs versions dans l'API ASP.NET coreWEB. Le package nuget prend en charge la gestion des versions via les paramètres de chaîne de requête, l'ajout de segments de chemin dans les URL et via les en-têtes. Il propose également des opérations API de version unique et la possibilité de désactiver les versions.

Est-il possible de contrôler la version d'une API sans recourir à des packages tiers ? Il existe des méthodes que je n'entrerai pas dans les détails.

Quatre versions Ultimate (sans aucun package NuGet) Contrôle de version de l'API Web principale asp.net

Créez un nouveau projet d'API principale :

Sous le dossier VersionControl, créez une nouvelle classe NameSpaceVersionRoutingConvention qui implémente l'interface IApplicationModelConvention. Le code est le suivant :

public class NameSpaceVersionRoutingConvention:IApplicationModelConvention
  {
    private readonly string apiPrefix;
    private const string urlTemplate = "{0}/{1}/{2}";
    public NameSpaceVersionRoutingConvention(string apiPrefix = "api")
    {
      this.apiPrefix = apiPrefix;
    }

    public void Apply(ApplicationModel application)
    {
      foreach (var controller in application.Controllers)
      {
        
        var hasRouteAttribute = controller.Selectors
        .Any(x => x.AttributeRouteModel != null);
        if (!hasRouteAttribute)
        {
          continue;
        }
        var nameSpaces = controller.ControllerType.Namespace.Split('.');
        //获取namespace中版本号部分
        var version = nameSpaces.FirstOrDefault(x => Regex.IsMatch(x, @"^v(\d+)$"));
        if (string.IsNullOrEmpty(version))
        {
          continue;
        }
        string template = string.Format(urlTemplate, apiPrefix, version,
        controller.ControllerName);
        controller.Selectors[0].AttributeRouteModel = new AttributeRouteModel()
        {
          Template = template
        };
      }
    }
  }

<.>Code de débogage On constate que cette méthode ne sera exécutée que lorsque le programme est exécuté pour la première fois, et ne sera pas exécutée plusieurs fois par la suite, elle est donc très efficace.

5.Résumé :

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!