Bienvenue dans un nouvel épisode des pépites de connaissances Microsoft, je suis votre autre Mirko Peters. Le sujet d'aujourd'hui est quelque chose dont presque tout le monde a entendu parler, mais que peu comprennent vraiment. Les API. Vous avez probablement entendu ce terme très souvent. C'est l'un de ces mots techniques que les gens utilisent pour paraître experts dans leur domaine. Et voici le fait, les API sont en réalité simples. Ce sont juste un moyen pour qu'un logiciel communique avec un autre. Votre téléphone demande des données à un serveur. Le serveur les renvoie. C'est ça, un appel API. Imaginez maintenant que vous ayez 20 API, ou 50, ou 100. Chacune peut utiliser une authentification différente, des limites de débit variées, et une documentation différente, voire inexistante. Soudainement, ce qui a commencé comme une simple conversation entre deux applications devient un chaos total.

Sans gestionnaire central, chaque équipe réinvente la roue. Une équipe crée son propre système d'authentification, une autre son propre système de journalisation. Des feuilles de sécurité apparaissent partout. Les développeurs ne savent plus quelle API fait quoi, et vous n'avez aucune vision globale de ce qui se passe dans votre système. Ah, Azure API Management Résouceau. Ils vous offrent un centre de contrôle unique. Voyez cela comme une tour de contrôle aérien pour vos API. A la fin de cet épisode, vous comprendrez ce que c'est, pourquoi c'est important, et comment tout cela s'articule. Prenez votre café, plongeons dans le sujet. Le problème, trop d'API, aucun contrôle. Voici la réalité des logiciels modernes. Il y a 10 ans, vous avez probablement une seule grosse application. Un monolithe, une base de données, une API, simple. Aujourd'hui, cette même application pourrait être décomposée en dizaines de microservices.

Chaque service gère une chose, compte utilisateur, paiement, inventaire, notification, et chacun expose sa propre API, et, soudainement, vous avez 10, 50, 100 points d'entrée différents dans votre système. Imaginez maintenant que vous soyez un développeur, essayant de construire quelque chose qui utilise ces API. Vous devez trouver chacune d'elles, comprendre l'authentification de chacune. Certaines utilisent des clés API, d'autres aux autres, certaines rien du tout. Vous devez gérer manuellement les limites de débit sous peine d'être bloquées. Vous devez comprendre le format de données attendu par chacune. C'est épuisant. Et cela empire du point de vue des opérations. Sans passerelle centrale, chaque équipe doit ajouter manuellement la sécurité et la journalisation à son propre service. Certaines équipes le font bien, d'autres oublient de journaliser les erreurs. Certaines ne valident même pas les entrées.

C'est incohérent et sujet aux erreurs. Un cauchemar de sécurité en devenir. La conformité devient presque impossible. Besoin de prouver qui a accédé à quoi et quand ? Bonne chance pour extraire les pistes d'audit de 20 services différents, chacun avec son propre format de journalisation. Besoin de savoir combien d'appels API votre système a traité le mois dernier ? Compiler des métriques provenant d'une douzaine de tableaux de bord différents. Voici le problème. A mesure que vous évoluez, cela ne se contente pas d'être pénible. Ça casse tout. Impossible d'ajouter plus de développeurs, de services ou de clients sans un point de contrôle central. Voyez cela comme un bâtiment. Imaginez que chaque pièce posait une sérieux différente. Il n'y a ni réception, ni annuaire. Les visiteurs errent pour trouver la bonne porte, sagacent et finissent par abandonner le chaos total. C'est le problème que la gestion d'API a été conçue pour résoudre.

Qu'est-ce qu'Azure API Management ? La tour de contrôle. Alors qu'est-ce qu'Azure API Management exactement ? Voici la définition la plus simple. C'est un service managé qui se place entre vos API back-end et les applications, sites web, appareils et partenaires qui les utilisent. Mais attention, ce n'est pas qu'un simple proxy. Un proxy transfère le trafic et c'est tout. Azure API Management couvre tout le cycle de vie de vos API. Publiez, sécurisez, surveillez et finissez par les retirer. C'est un centre de contrôle complet. Décomposons cela en trois composants principaux. Le premier est la passerelle. C'est la porte d'entrée. Chaque requête entrente d'une application ou d'un site web frappe d'abord la passerelle, jamais votre back-end directement. La passerelle traite la requête, applique vos politiques, collecte des métriques, puis la transfère au bon service back-end. Considérez-la comme un agent de circulation.

Vient ensuite le plan de gestion. C'est là que vous définissez tout. Vos API, vos politiques, vos produits, vos abonnements. Vous faites cela via le portail Azure, la ligne de commande, l'infrastructure Ascode, comme Bicep ou Terraform. C'est la salle de contrôle où vous configurez le fonctionnement de tout. Et ensuite le portail des développeurs. C'est un site en libre-service où les développeurs internes ou externes peuvent découvrir vos API, lire la documentation, obtenir des clés d'abonnement. Et même tester les appels API directement dans leur navigateur. Eh ! Fini l'échange incessant de PDF par email. Voici une analogie utile. Pensez à un aéroport moderne. La passerelle et la piste d'atterrissage. Chaque avion y atterrit en premier. Le plan de gestion et la tour de contrôle. Elle dirige le trafic, définit les règles et surveille tout. Et le portail des développeurs et le panneau d'informations.

Les pilotes le consultent avant de voler et trouvent toutes les informations nécessaires sans parler à personne. Maintenant, zoom-on sur la passerelle. C'est la partie à laquelle vos applications parlent réellement et là où la magie opère. La passerelle, la porte d'entrée de vos API. Parlons de la passerelle car c'est la partie avec laquelle vos applications communiquent réellement. Chaque requête venant d'une application mobile, d'un site web ou d'un appareil IoT atteint d'abord la passerelle. Jamais votre back-end directement. C'est tout l'intérêt. La passerelle se place devant et agit comme un point d'entrée unique. La passerelle peut appliquer des stratégies avant de transmettre la requête. Les stratégies sont des règles que vous écrivez en XML ou en JSON, comme la limitation de débit, le filtre à JP, la réécriture d'entête et les contrôles d'authentification. Le tout sans changer une seule ligne de votre code back-end.

Voici un exemple concret. Disons que vous avez une offre gratuite et une offre premium pour votre API. Avec une stratégie, vous pouvez limiter les utilisateurs gratuits à 5 requêtes par minute, tandis que les utilisateurs premium en obtiennent 100. Votre back-end ne voit jamais la différence. Il traite simplement les requêtes. La passerelle gère l'application des règles. La passerelle gère également la mise en cache. Si des données sont demandées à répétition, comme une liste de produits qui changent rarement, la passerelle peut mettre la réponse en cache et la servir directement. Et la servir directement. Il n'est pas nécessaire de solliciter votre back-end, ce qui signifie des réponses plus rapides et moins de charges sur vos serveurs. Elle peut aussi transformer les données. Votre back-end peut renvoyer du XML alors que votre application mobile attend du JSON. La passerelle peut le convertir à la volée.

Votre back-end n'a pas besoin de changer et votre application non plus. Et... et... La passerelle gère la traduction. Et elle enregistre chaque appel, chaque requête, chaque réponse, chaque erreur. Vous obtenez une piste d'audit complète de qui a appelé quoi, quand et ce qui s'est passé. Rien que cela justifie l'investissement pour la conformité. Si vous avez une audience mondiale, vous pouvez déployer la passerelle dans plusieurs régions. Le trafic est automatiquement routé vers la plus proche, ce qui réduit la latence et améliore l'expérience. Une dernière chose, la passerelle masque l'URL réelle de votre back-end. Les clients ne voient que l'adresse de la passerelle. Vos serveurs back-end restent cachés d'internet. C'est un énorme avantage en matière de sécurité de la maison service. Les stratégies, le moteur qui contrôle tout... Alors qu'en est-il de ces stratégies que j'ai mentionnées ?

Ce sont le moteur qui rend la gestion d'API vraiment puissante. Une stratégie modifie le comportement des requêtes ou des réponses sans jamais toucher à votre code back-end. Voyez cela comme une enveloppe autour de votre API. A mesure que le trafic circule, elle peut ajouter, supprimer ou modifier des éléments automatiquement. Les stratégies peuvent s'exécuter à 4 moments du cycle vide de la requête. En entrée, à l'arrivée, avant que la requête n'atteigne votre back-end, en sortie, au retour, avant que la réponse ne parvienne au client. Back-end, juste avant que la requête n'atteigne votre service. Et en cas d'erreur, lorsqu'un problème survient. Les tâches entrantes courantes incluent la validation de jetons JWT pour vérifier l'identité de l'appelant, la vérification des clés API, la réécriture d'URL et la restriction par adresse IP. Tout cela se produit avant que votre back-end ne reçoive la moindre requête.

Pour les flux sortants, vous pouvez transformer le corps de la réponse. Rechercher et remplacer du texte, supprimer des champs sensibles, changer des formats. Vous pouvez mettre les réponses en cache pour que les requêtes répétées n'atteignent pas votre back-end. Vous pouvez même supprimer les entêtes qui divulguent des informations internes. Voici un exemple concret. Imaginez que votre API renvoie des descriptions de produits contenant le mot bleu partout. Vous souhaitez changer l'image de marque et utiliser jaune à la place. Au lieu de modifier le code de votre back-end, vous ajoutez une stratégie sortante. Rechercher bleu, remplacer par jaune, c'est tout. Votre back-end ne change jamais. Les stratégies de limitation de débit de quota protègent votre back-end contre les abus. Si une application devient incontrôlable et bombarde votre API dix et mille fois par seconde, la stratégie intervient et digue à ralentissez à gueule.

Votre back-end reste sain. Il y a besoin d'une logique avancée. Vous pouvez écrire des expressions séchères personnalisées au sein des stratégies. Elles sont compilées pour garantir l'apparemment. Il n'y a donc aucun coût à l'exécution. Vous pouvez rechercher des rôles d'utilisateur, calculer des limites de débit dynamique ou transformer conditionnellement des réponses selon les entêtes de requêtes. Voici le point essentiel à retenir. Les stratégies vous permettent de contrôler le comportement de vos API sans toucher au code qui les exécute. Cela signifie des changements plus rapides, moins déploiements et moins de risques. Produits et abonnements. Packagez les API pour les consommateurs. Maintenant vos API sont définis, les stratégies sont en place et la passerelle fonctionne à merveille. Mais comment donner à différents clients accès à différentes choses ? C'est là qu'interviennent les produits et les abonnements.

Dans Appim, vous regroupez les API dans ce qu'on appelle un produit. Considérez cela comme un bon. Pour y avoir un produit gratuit qui inclut seulement vos API de base. Peut-être juste un accès en lecture seul. Puis un produit premium inclus en tout, y compris les opérations d'écriture et les points de terminaison d'administration. Les développeurs ne s'abonnent pas à des API individuels et s'abonnent à un produit. Lorsqu'ils s'abonnent, ils reçoivent une clé d'abonnement. Faites deux clés pour pouvoir en renouveler une sans interruption de service. Cette clé est leur laissée passer pour utiliser toute API présente dans ce produit. Vous contrôlez le fonctionnement des abonnements. Les produits peuvent nécessiter une approbation. Vous acceptez manuellement chaque abonné, ou ils peuvent être ouverts au libre service. N'importe qui s'inscrit obtient un accès immédiat. Vous pouvez également inclure des conditions légales que les utilisateurs doivent accepter en sa bonne.

C'est important si vos API traitent des données sensibles. C'est ainsi que vous monétisez vos API. Un produit gratuit avec des limites de débit basse, 5 appels par minute. Un produit payant avec des limites plus élevées ou plus de points de terminaison. 100 appels par minute, plus l'accès à des fonctionnalités premium. Votre maquette ne s'en soucie pas. La passerelle applique les limites en fonction du produit auquel la plan a souscrit. Voici un exemple concret. Imaginez que vous créez une application de conférence. Vous créez un produit pour les participants avec des API pour le planning, les bio des intervenants et le plan du site. Puis un produit pour les sponsors qui inclut aussi des API de génération de leads. Les sponsors peuvent scanner les badges des participants et obtenir leurs coordonnées. Même backend, produits différents, niveau d'accès différents. Ces deux clés d'abonnement sont conçues pour la rotation.

Si une clé est compromise, vous en générez une nouvelle. La deuxième clé vous permet de basculer sans interrompre le service. Générez une nouvelle clé, mettez à jour votre application, révoquez l'ancienne. En toute transparence, le portail développeur, le libre service pour les consommateurs d'API. Vous avez donc configuré vos produits API. Maintenant les développeurs doivent les trouver. C'est le rôle du portail développeur. Le portail développeur est un site web intégré à chaque instance APM. Les développeurs l'utilisent pour parcourir vos API, lire la documentation et tester les points de terminaison directement dans leur navigateur. Aucune configuration requise et aucun échange d'email. Mais attention, il n'est pas publié par défaut. Lorsque vous créez votre instance APM, le portail existe mais personne ne peut le voir. Vous devez d'abord le personnaliser et le publier. C'est intentionnel.

Vous ne voulez pas montrer un portail inachevé au monde entier. Vous pouvez personnaliser les couleurs, les logos et même intégrer du contenu WordPress pour un blog à côté de vos docs API. Il est entièrement personnalisable pour correspondre à l'image de votre entreprise. La vraie valeur réside dans le libre service. Les développeurs s'inscrivent, obtiennent leur clé d'abonnement automatiquement et commencent à appeler les API immédiatement. Pas d'email manuel, pas d'attente d'approbation, pas de ticket de support demandant comment obtenir une clé. Ils le font eux-mêmes, ce qui réduit considérablement votre charge de support. Vous pouvez également publier des journaux de modification. Lorsque vous mettez à jour une API, les développeurs le voient sur le portail sans surprise. L'accès peut être public pour toute personne ayant l'URL ou restreint aux utilisateurs de votre tenant EntraID pour que seuls les membres de votre organisation puissent y accéder.

Les deux options existent pour différents cas d'usage. Le portail développeur fait de votre gestion d'API une véritable plateforme. Considérez-le comme la vitrine de vos API. Sans lui, les développeurs doivent fouiller dans la doc et poser des questions. Avec lui, ils trouvent ce dont ils ont besoin et commencent à coder. Sécurité, authentification, autorisation et secrets. Toute cette puissance est inutile si la sécurité n'est pas verrouillée. Parlons donc de la manière dont la PIM gère l'identité, l'accès et les secrets. La PIM prend en charge plusieurs méthodes d'authentification. La plus simple est celle des clés d'abonnement dont nous avons parlé plus tôt. Cependant, pour les systèmes en production, il vous faut une protection renforcée comme OOS 2.0, les jetons JWT, les certificats clients ou le filtrage IP, ou superposer ces couches selon le niveau de sensibilité de votre API. Pour la production, la meilleure pratique consiste à utiliser OOS 2.0 avec EntraID.

Voici comment cela fonctionne. L'application cliente obtient un jeton auprès d'EntraID et l'envoie avec la requête API. PIM valide le jeton en vérifiant la signature, l'émetteur, l'audience et l'expiration. S'il est valide, PIM transmet la requête à votre backend, jeton inclus. Votre backend lui fait confiance, car PIM l'a déjà vérifié, évitant ainsi une nouvelle validation. Bah, c'est une gestion de moins à assurer pour chaque service. Parlons maintenant des secrets. Clé d'API, chaîne de connexion, certificat. Vous ne voulez pas qu'il soit codé en dur dans les fichiers de politique ou le contrôle de source. PIM dispose d'une fonctionnalité appelée Valeurs Nommées. Vous stockez les secrets de manière centralisée dans PIM et les référencer par leur nom dans vos politiques. La valeur réelle n'apparaît jamais dans le code de votre politique. Mieux encore, vous pouvez connecter les valeurs nommées à Azure Key Vault.

Les secrets restent chiffrés dans Key Vault et PIM les récupère lors de l'exécution. Personne, pas même votre équipe DevOps, ne voit la valeur réelle du secret. Lorsque vous devez renouveler une clé, vous la mettez à jour dans Key Vault et PIM prend en compte le changement automatiquement. PIM prend également en charge les identités gérées. Cela permet à PIM de s'authentifier auprès d'autres services Azure, comme Key Vault ou une API backend, sans stocker d'identifiant. Azure gère l'identité, il vous suffit donc d'accorder les autorisations. Et pour l'isolation réseau, vous pouvez déployer APIM au sein d'un réseau virtuel, c'est le niveau premium. Ou utiliser Azure Front Door, l'essentiel est que vos services backend n'aient jamais besoin d'être exposés directement à Internet. APIM est la seule chose que le monde extérieur peut voir. Cette approche multicouche renforce la défense en profondeur.

Authentification à la passerelle, secret dans un coffre-fort, isolation réseau autour de vos backend. Chaque couche renforce la suivante. Niveau de tarification, lequel vous convient. Alors quel est le coût ? Passons en revue les différents niveaux. Le niveau consommation. Payé par appel API sans coût mensuel fixe. Parfait pour les faibles volumes ou les charges de travail irrégulières comme lors du prototypage. Si vous n'êtes pas encore sûr de vos besoins, commencez par là. Le niveau développeur offre un coût mensuel fixe bas à environ 50$. Jeu complet de fonctionnalités mais sans SLA. Idéal pour les environnements de développement et de tests. Vous bénéficiez de tout ce que propose le niveau premium mais sans pouvoir l'utiliser en produit. Le niveau basique est une offre d'entrée de gain pour la production. Débit plus faible, pas de support de réseau virtuel mais vous bénéficiez d'un véritable SLA.

Adapté aux outils internes ou aux petits projets où le réseau privé n'est pas critique. La plupart des entreprises optent pour le niveau standard. Il inclut la prise en charge des réseaux virtuels, un SLA de 99,89 sans un bon débit. Si vous exécutez des API critiques pour votre activité, c'est probablement là que vous vous orienterez. Le niveau premium est destiné aux entreprises mondiales ayant besoin d'une fiabilité maximale et de réseaux privés. Déploiement multi-région, passerelle auto-hébergée SLA de 99,89 sans injection complète dans un réseau virtuel. A partir d'environ 2,700 par mois et par unité. Microsoft a également introduit les niveaux V2. Basic V2, Standard V2, Premium V2. Il simplifie la tarification avec des quotas de requêtes inclus, une facturation par million d'unités excès. Au lieu de suivre plusieurs compteurs, vous bénéficiez d'un volume de requêtes claires et payez l'utilisation supplémentaire par palier simple.

Voici comment choisir. Commencez avec le niveau développeur pour les tests. Passez au standard pour la production. Optez pour le premium si vous avez besoin d'une échelle mondiale ou d'un réseau privé. Et n'oubliez pas que vous pouvez toujours migrer vers d'autres niveaux plus tard. Commencez petit et évoluez selon vos besoins. Voici ce que nous avons couvert. La gestion d'API transforme le chaos de nombreuses APIs en un centre de contrôle unique pour la passerelle, les politiques, la sécurité et l'expérience développeur. L'essentiel est de retenir qu'il s'agit de bien plus qu'un simple principe. Considérez cela comme le cerveau et le système nerveux de votre écosystème d'API. Sans cela, chaque équipe crée sa propre authentification, journalisation et limitation de débito. Vous vous retrouvez avec des incohérences, des failles de sécurité et aucune vue centralisée de ce qui se passe. Avec, vous bénéficiez de cohérence, de sécurité et d'évolutivité, sans réinventer la roue pour chaque service.

Voici un exercice simple. Pensez à une API que vous exposez actuellement directement. Peut-être un point de termaison de fonction ou un service d'application. Comment le fait de placer la gestion d'API en amont changerait-il votre posture de sécurité et votre capacité à surveiller l'utilisation ? Rien que le fait de réfléchir à cet exercice vous en démontrera la valeur. Prochaine étape, abonnez-vous à la chaîne. Dans les prochains épisodes, nous vous montrerons comment importer une API, appliquer votre première politique et surveiller l'utilisation en temps réel. Vous passerez de la théorie à la pratique. Si vous avez trouvé cela utile, partagez-le avec quelqu'un qui développe une application. Cela leur évitera des mois de mot de tête. Merci de nous avoir écouté. Merci.