Une passerelle d'API se justifie quand plusieurs services distincts doivent être exposés derrière une seule adresse, avec une authentification et des quotas par client ; elle ne se justifie pas devant une simple application web. Cette leçon vous donne le critère de décision en quatre situations types, et l'effet de sa tarification à la requête. Elle s'adresse à qui doit choisir ce qu'on place devant une application exposée, sans avoir encore utilisé de passerelle.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Définir ce qu'est une passerelle d'API et ce qu'elle ajoute à un répartiteur de charge.
- Décider entre passerelle et répartiteur de niveau 7 pour une situation donnée.
- Expliquer pourquoi la facturation à la requête change le calcul pour un service à fort trafic.
Prérequis
Section intitulée « Prérequis »- Savoir ce que fait un répartiteur de charge de niveau 7 : il route les requêtes HTTP vers des serveurs sains et termine TLS. Voir Load Balancing : répartition de charge L4, L7 et terminaison TLS.
- Avoir lu la leçon Exposer une application : bordure, CDN, WAF et anti-DDoS, qui situe la passerelle parmi les services de bordure.
Qu'est-ce qu'une passerelle d'API ?
Section intitulée « Qu'est-ce qu'une passerelle d'API ? »Une passerelle d'API est un point d'entrée unique qui reçoit les appels adressés à plusieurs services, les authentifie, limite le débit de chaque client, puis les route vers le bon service. Elle centralise des fonctions que chaque service devrait sinon réimplémenter : vérification d'une clé ou d'un jeton, quotas par client, journal des appels. Elle n'accélère rien, et elle ajoute un intermédiaire de plus sur le chemin de chaque requête.
Quand une passerelle d'API se justifie-t-elle ?
Section intitulée « Quand une passerelle d'API se justifie-t-elle ? »Elle se justifie dès que plusieurs services, ou plusieurs clients à distinguer, partagent une même entrée. Dans ce cas précis, elle évite de réimplémenter la même logique dans chaque service, et c'est un vrai gain.
Elle ne se justifie pas quand vous exposez une seule application web. Un répartiteur de niveau 7 fait déjà le routage et la terminaison TLS ; ajouter une passerelle devant lui rajoute une latence, un point de panne et une ligne de facture pour un service qui ne rend aucun service supplémentaire.
Le tableau se lit en partant de votre situation : la colonne de droite est la réponse minimale suffisante, pas la plus complète.
| Votre situation | La bonne réponse |
|---|---|
| Une application web servie à des navigateurs | répartiteur de niveau 7, rien de plus |
| Une API publique avec des clés par client et des quotas | passerelle d'API, c'est son cas d'usage |
| Plusieurs microservices exposés sous un domaine unique | passerelle d'API, ou un routage applicatif si le nombre reste faible |
| Des fonctions serverless (du code exécuté à la demande, sans serveur à gérer) appelées en HTTP | passerelle d'API, souvent imposée par le fournisseur |
Un exemple pour fixer le critère. Une boutique en ligne qui sert son site à des navigateurs n'a pas besoin de passerelle : le répartiteur suffit. La même entreprise qui ouvre une API à deux cents partenaires, chacun avec sa clé et son quota d'appels par minute, a besoin d'un endroit unique pour vérifier la clé et compter les appels. C'est exactement ce que la passerelle apporte, et ce que le répartiteur ne sait pas faire.
Pourquoi la tarification peut-elle jouer contre la passerelle ?
Section intitulée « Pourquoi la tarification peut-elle jouer contre la passerelle ? »Une passerelle d'API se facture à la requête, un répartiteur à l'heure et au volume traité : pour un service à fort trafic et petites réponses, l'écart de facture peut devenir considérable, et il joue contre la passerelle. C'est la raison pour laquelle le choix ne se fait pas seulement sur les fonctions. Avant d'en poser une, estimez le nombre de requêtes par mois et multipliez-le par le tarif unitaire publié par votre fournisseur, puis comparez au coût horaire d'un répartiteur.
À retenir
Section intitulée « À retenir »- Une passerelle d'API authentifie, limite le débit par client et route vers plusieurs services ; elle n'accélère rien et ajoute un intermédiaire.
- Devant une seule application web, un répartiteur de niveau 7 suffit : il route et termine TLS.
- Une API publique avec clés et quotas par client est le cas d'usage de la passerelle.
- Les fonctions serverless exposées en HTTP passent souvent par une passerelle, parfois imposée par le fournisseur.
- La facturation à la requête peut inverser le calcul pour un fort trafic : estimez le volume avant de choisir.
Contrôle de connaissances
Section intitulée « Contrôle de connaissances »Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Continuer le cours : Point de terminaison privé : joindre un service managé sans Internet
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications