Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Modèles de routage des API
Dans les environnements de développement agiles, les équipes autonomes (par exemple les escadrons et les tribus) possèdent un ou plusieurs services qui incluent de nombreux microservices. Les équipes exposent ces services de manière APIs à permettre à leurs consommateurs d'interagir avec leur groupe de services et d'actions.
Il existe trois méthodes principales pour exposer le protocole HTTP APIs aux consommateurs en amont en utilisant des noms d'hôtes et des chemins :
|
|
| **Method** | **Description** | **Exemple** |
| --- |--- |--- |
| [**Routage du nom d’hôte**](api-routing-hostname.md) | Exposez chaque service sous forme de nom d’hôte. | `billing.api.example.com` |
| [**Routage des chemins**](api-routing-path.md) | Exposez chaque service sous forme de chemin. | `api.example.com/billing` |
| [**Routage basé sur les en-têtes**](api-routing-http.md) | Exposez chaque service sous forme d’en-tête HTTP. | `x-example-action: something` |
Cette section décrit les cas d’utilisation typiques de ces trois méthodes de routage et leurs compromis pour vous aider à choisir la méthode la mieux adaptée à vos besoins et à votre structure organisationnelle.
# Schéma de routage du nom d’hôte
Le routage par nom d’hôte est un mécanisme permettant d’isoler les services d’API en attribuant à chaque API son propre nom d’hôte ; par exemple, `service-a.api.example.com` ou `service-a.example.com`.
## Cas d’utilisation types
Le routage à l’aide de noms d’hôtes réduit les frictions lors des lancements, car rien n’est partagé entre les équipes de service. Les équipes sont chargées de tout gérer, des entrées DNS aux opérations de service en production.
![\[Modèle de routage du nom d'hôte pour exposer le protocole HTTP APIs aux consommateurs en amont.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/cloud-design-patterns/images/routing-1.png)
## Avantages
Le routage par nom d’hôte est de loin la méthode la plus simple et la plus évolutive pour le routage d’API HTTP. Vous pouvez utiliser n'importe quel AWS service approprié pour créer une architecture qui suit cette méthode. Vous pouvez créer une architecture avec [Amazon API Gateway [AWS AppSync](https://aws.amazon.com/appsync/)](https://aws.amazon.com/api-gateway/), les [équilibreurs de charge d'application et](https://aws.amazon.com/elasticloadbalancing/) [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/), ou tout autre service compatible HTTP.
Les équipes peuvent utiliser le routage par nom d’hôte pour être entièrement propriétaires de leur sous-domaine. Cela facilite également l'isolation, le test et l'orchestration de déploiements pour des versions Régions AWS ou des versions spécifiques ; par exemple, `region.service-a.api.example.com` ou. `dev.region.service-a.api.example.com`
## Inconvénients
Lorsque vous utilisez le routage par nom d’hôte, vos clients doivent mémoriser différents noms d’hôte pour interagir avec chaque API que vous exposez. Vous pouvez atténuer ce problème en fournissant un kit SDK client. Cependant, le SDKs client a ses propres défis à relever. Par exemple, ils doivent prendre en charge les mises à jour propagées, le multilinguisme, la gestion des versions, la communication des modifications majeures causées par des problèmes de sécurité ou des corrections de bogues, la documentation, etc.
Lorsque vous utilisez le routage par nom d'hôte, vous devez également enregistrer le sous-domaine ou le domaine chaque fois que vous créez un nouveau service.
# Schéma de routage des chemins
Le routage par chemins est le mécanisme qui consiste à regrouper plusieurs ou tous APIs sous le même nom d'hôte et à utiliser une URI de demande pour isoler les services ; par exemple, `api.example.com/service-a` ou`api.example.com/service-b`.
## Cas d’utilisation types
La plupart des équipes optent pour cette méthode, car elles souhaitent une architecture simple : un développeur ne doit mémoriser qu’une seule URL, par exemple `api.example.com`, pour interagir avec l’API HTTP. La documentation des API est souvent plus facile à digérer car elle est souvent conservée ensemble au lieu d'être répartie sur différents portails ou PDFs.
Le routage basé sur le chemin est considéré comme un mécanisme simple de partage d’une API HTTP. Cependant, il implique des frais opérationnels tels que la configuration, les autorisations, les intégrations et une latence supplémentaire due aux sauts multiples. Cela nécessite également des processus de gestion des modifications matures pour garantir qu’une mauvaise configuration ne perturbe pas tous les services.
Oui AWS, il existe plusieurs manières de partager une API et de l'acheminer efficacement vers le bon service. Les sections suivantes présentent trois approches : le service HTTP, le proxy inverse, API Gateway et Amazon CloudFront. Aucune des approches proposées pour unifier les services d’API ne repose sur l’exécution des services en aval sur AWS. Les services peuvent fonctionner n’importe où sans problème ou sur n’importe quelle technologie, à condition qu’ils soient compatibles avec le protocole HTTP.
## Proxy inverse de service HTTP
Vous pouvez utiliser un serveur HTTP tel que [NGINX](https://www.f5.com/go/product/welcome-to-nginx) pour créer des configurations de routage dynamiques. Dans une architecture [Kubernetes](https://kubernetes.io/), vous pouvez également créer une règle d’entrée correspondant à un chemin d’accès à un service. (Ce guide ne couvre pas l’entrée dans Kubernetes ; veuillez consulter la documentation de [Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource) pour plus d’informations.)
La configuration suivante de NGINX mappe dynamiquement une demande HTTP de `api.example.com/my-service/` vers `my-service.internal.api.example.com`.
```
server {
listen 80;
location (^/[\w-]+)/(.*) {
proxy_pass $scheme://$1.internal.api.example.com/$2;
}
}
```
Le schéma suivant illustre la méthode du proxy inverse de service HTTP.
![\[Utilisation d’un proxy inverse de service HTTP pour le routage des chemins.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/cloud-design-patterns/images/routing-2.png)
Cette approche peut être suffisante pour certains cas d’utilisation qui n’utilisent pas de configurations supplémentaires pour commencer à traiter les demandes, ce qui permet à l’API en aval de collecter des métriques et des journaux.
Pour être prêt à être opérationnel en production, vous devez être en mesure d’ajouter de l’observabilité à chaque niveau de votre pile, d’ajouter une configuration supplémentaire ou d’ajouter des scripts pour personnaliser votre point d’entrée d’API afin de permettre des fonctionnalités plus avancées telles que la limitation du débit ou les jetons d’utilisation.
### Avantages
L'objectif ultime de la méthode de proxy inverse du service HTTP est de créer une approche évolutive et gérable pour l'unification APIs en un seul domaine afin qu'elle apparaisse cohérente pour tout consommateur d'API. Cette approche permet également à vos équipes de service de déployer et de gérer leurs propres équipes APIs, avec un minimum de frais généraux après le déploiement. AWS les services gérés pour le traçage, tels que [AWS X-Ray](https://aws.amazon.com/xray/)ou [AWS WAF](https://aws.amazon.com/waf/), sont toujours applicables ici.
### Inconvénients
Le principal inconvénient de cette approche réside dans les tests et la gestion approfondis des composants d’infrastructure nécessaires, bien que cela ne pose peut-être aucun problème si vous disposez d’équipes d’ingénierie de fiabilité des sites (SRE) en place.
Cette méthode comporte un point de bascule en matière de coûts. Pour des volumes faibles à moyens, elle est plus coûteuse que certaines des autres méthodes décrites dans ce guide. Pour des volumes élevés, elle est très rentable (environ 100 000 transactions par seconde ou mieux).
## API Gateway
Le service [Amazon API Gateway](https://aws.amazon.com/api-gateway/) (REST APIs et HTTP APIs) peut acheminer le trafic d'une manière similaire à la méthode de proxy inverse du service HTTP. L’utilisation d’une passerelle API en mode proxy HTTP fournit un moyen simple de regrouper de nombreux services dans un point d’entrée vers le sous-domaine de premier niveau `api.example.com`, puis de transmettre des demandes proxy au service imbriqué, par exemple `billing.internal.api.example.com`.
Vous ne voulez probablement pas être trop précis en mappant chaque chemin de chaque service dans la passerelle d’API racine ou principale. Optez plutôt pour des chemins génériques, par exemple `/billing/*`, pour transférer les demandes au service de facturation. En ne mappant pas tous les chemins de la passerelle d'API racine ou principale, vous gagnez en flexibilité par rapport à votre passerelle d'API APIs, car vous n'avez pas à mettre à jour la passerelle d'API racine à chaque modification d'API.
![\[Routage des chemins via API Gateway.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/cloud-design-patterns/images/routing-3.png)
### Avantages
Pour contrôler des flux de travail plus complexes, tels que la modification des attributs des demandes, REST APIs expose le langage de modèle Apache Velocity (VTL) pour vous permettre de modifier la demande et la réponse. REST APIs peut apporter des avantages supplémentaires tels que les suivants :
+ [Authentification N/Z avec Gestion des identités et des accès AWS (IAM),](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/authentication.html) [[Amazon Cognito ou](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/cognito.html) des autorisateurs AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)
+ [AWS X-Ray pour le traçage](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-understanding-xray-traces.html)
+ [Intégration avec AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)
+ [Limitation du taux de base](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ Utilisation de jetons pour compartimenter les consommateurs en différents niveaux (veuillez consulter [Limiter les demandes d’API pour améliorer le débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) dans la documentation d’API Gateway)
### Inconvénients
Pour des volumes élevés, le coût peut être un problème pour certains utilisateurs.
## CloudFront
Vous pouvez utiliser la [fonction de sélection dynamique de l'origine d'](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html)[Amazon CloudFront](https://aws.amazon.com/cloudfront/) pour sélectionner de manière conditionnelle une origine (un service) afin de transférer la demande. Vous pouvez utiliser cette fonctionnalité pour acheminer un certain nombre de services via un seul nom d’hôte, tel que `api.example.com`.
### Cas d’utilisation types
La logique de routage fonctionne sous forme de code au sein de la fonction Lambda @Edge. Elle prend donc en charge des mécanismes de routage hautement personnalisables tels que les A/B tests, les versions Canary, le marquage des fonctionnalités et la réécriture de chemins. Le diagramme suivant en est l’illustration.
![\[Parcours de routage CloudFront.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/cloud-design-patterns/images/routing-4.png)
### Avantages
Si vous avez besoin de mettre en cache les réponses des API, cette méthode est un bon moyen d’unifier un ensemble de services derrière un seul point de terminaison. Il s'agit d'une méthode rentable pour unifier les collections de APIs.
Il prend également CloudFront en charge [le chiffrement au niveau du champ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html) ainsi que l'intégration avec AWS WAF pour la limitation du débit de base et de base. ACLs
### Inconvénients
Cette méthode prend en charge un maximum de 250 origines (services) qui peuvent être unifiées. Cette limite est suffisante pour la plupart des déploiements, mais elle peut entraîner des problèmes avec un grand nombre de déploiements à APIs mesure que vous développez votre portefeuille de services.
La mise à jour des fonctions Lambda @Edge prend actuellement quelques minutes. CloudFront il faut également jusqu'à 30 minutes pour terminer la propagation des modifications à tous les points de présence. Cela bloque finalement les mises à jour ultérieures jusqu’à ce qu’elles soient terminées.
# Modèle de routage des en-têtes HTTP
Le routage basé sur les en-têtes vous permet de cibler le service approprié pour chaque demande en spécifiant un en-tête HTTP dans la requête HTTP. Par exemple, l’envoi de l’en-tête `x-service-a-action: get-thing` vous permettra de `get thing` à partir de `Service A`. Le chemin de la demande est toujours important, car il fournit des indications sur la ressource sur laquelle vous essayez de travailler.
En plus d'utiliser le routage des en-têtes HTTP pour les actions, vous pouvez l'utiliser comme mécanisme de routage des versions, en activant des indicateurs de fonctionnalité, A/B des tests ou des besoins similaires. En réalité, vous utiliserez probablement le routage des en-têtes avec l'une des autres méthodes de routage pour créer une solution robuste APIs.
L’architecture du routage des en-têtes HTTP comporte généralement une fine couche de routage devant les microservices qui achemine vers le service approprié et renvoie une réponse, comme illustré dans le schéma suivant. Cette couche de routage peut couvrir tous les services ou seulement quelques services pour permettre une opération telle que le routage basé sur les versions.
![\[Routage des en-têtes HTTP.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/cloud-design-patterns/images/routing-5.png)
## Avantages
Les modifications de configuration nécessitent un minimum d’efforts et peuvent être automatisées facilement. Cette méthode est également flexible et permet de créer des moyens créatifs pour n’exposer que les opérations spécifiques que vous souhaitez obtenir d’un service.
## Inconvénients
Comme pour la méthode de routage par nom d’hôte, le routage des en-têtes HTTP suppose que vous avez un contrôle total sur le client et que vous pouvez manipuler des en-têtes HTTP personnalisés. Les proxys, les réseaux de diffusion de contenu (CDNs) et les équilibreurs de charge peuvent limiter la taille de l'en-tête. Bien que cela ne soit pas un problème, cela peut poser problème en fonction du nombre d’en-têtes et de cookies que vous ajoutez.