Azure API Management : Introduction — Version Française

Une “Application Programming Interfaces” (API) a un cycle de vie qui commence de la conception et s’arrête à la dépréciation. Le défi majeur des entreprises est de faire face à la demande quotidienne d’amélioration et d’ajout de nouvelles APIs.

Les entreprises peuvent affronter ce défi en créant rapidement les APIs. Elles ne devront pas se poser la question sur la façon par laquelle on exposera l’API, comment est ce qu’on assurera une sécurité de très haut niveau ou contrôler les APIs. Les clients (internes qu’ils soient ou externes) doivent pouvoir consommer les APIs publiées.

Azure API Management est une solution Microsoft permettant l’administration et la publication des APIs. C’est une façon de créer, provisionner et gérer les APIs. En utilisant APIM, le client peut :

• Imposer une sécurité de très grand niveau en s’authentifiant et en gérant les accès;
• Contrôler les APIs en utilisant les “policies”;
• Versionner les APIs;
• Surveiller et fournir des informations sur l’état des APIs.

Azure API Management offre trois types de services :

• Developer Portal :

Les développeurs peuvent accéder et tester les APIs publiées à travers le Developer Portal.

• API Gateway :

L’API Gateway est un proxy qui assure la connexion avec le backend.

• Publisher Portal :

Le Publisher Portal est une interface qui permet aux personnes qui publient les APIs de configurer et gérer leurs APIs.

Déployer Azure API Management en utilisant une ARM Template

Déployer une instance d’API Management n’est pas difficile. On peut créer une Template ARM qui la déploie rapidement :

Des définitions basiques

Une fois que votre APIM est déployée et démarrée, vous devez être conscient de plusieurs définitions.

Commençons par l’API. C’est l’API que vous souhaitez publier. Si votre besoin est d’utiliser plusieurs versions en parallèles, vous devez alors utiliser ce qu’on appelle “Version Set”. C’est facile à comprendre :

En utilisant APIM, on peut définir autant de versions qu’on veut. On peut définir un schema d’une version. Si jamais un client souhaite envoyer une requête vers une version X, il n’aura qu’à ajouter un “query parameter” à la fin par exemple. Dans le schema ci-dessus, on a “myapp-version”.

Si la version n’est pas importante, vous pouvez utiliser les révisions. Contrairement au Version Set, les révisions ne permettent pas d’envoyer une requête vers plusieurs versions, mais que vers la révision qui est activée.

Quand un client envoie une requête, elle sera directement passée vers la révision courante. Vous pouvez mettre n’importe quelle révision comme étant courante.

Comment créer une API en utilisant REST API :

Supposons qu’on a un fichier swagger qui décrit notre API.

Tout d’abord, on doit créer une API Version Set pour regrouper toutes les versions d’une API. C’est une requête PUT.

Après, On doit créer une API et la relier avec l’API Version Set qu’on vient de créer.

Si on exécute ces scripts, on doit voir apparaître une Version Set et notre API à l’intérieur de la Version Set.

On opte de passer à travers les scripts pour pouvoir les intégrer dans une CI/CD Pipeline.

On a crée l’API, mais on n’a pas terminé. On doit contrôler les accès, sécuriser et contrôler l’API. Comment faire ? En utilisant les produits et les policies.

API Management possède une fonctionnalité qui s’appelle Produits. Ils sont un groupe logique de plusieurs APIs. Si on applique une règle sur un produit, elle sera donc appliquée sur toutes les APIs qui font partie du produit.

Pour créer un produit, on peut utiliser les ARM Templates.

Si on déploie cette ARM Template, on doit voir apparaître un produit dans APIM.

L’accès peut être donné à un groupe (qui est un ensemble des utilisateurs). La bonne nouvelle c’est qu’on peut créer les groupes et les utilisateurs en utilisant les ARM Templates.

En utilisant les produits, on peut contrôler l’accès à toutes les APIs qui y sont? Mais comment peut-on lier une API à un Produit ? Bonne question. En utilisant le REST API, on peut créer une API directement à l’intérieur d’un produit (ça reste mieux que de créer une API et la mettre à jour après).

Azure DevOps : Configurer automatiquement une instance d’API Management

Maintenant qu’on a toutes les ARM Templates, on peut utiliser un outil DevOps pour automatiser la configuration d’APIM (à savoir la création de l’APIM, des utilisateurs et groupes, des produits et du backend si vous en avez besoin).

J’ai utilisé Azure DevOps comme outil. Premièrement, j’ai poussé les Templates à l’intérieur de Repos.

Une fois poussé, je peux utiliser Repos comme Artifact.

Je crée les tâches qui permettent de déployer la configuration

Chaque tâche doit référencer l’ARM Template correspondante.

Bella ciao,