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.
Route les demandes d’API entrantes directes vers les ressources dorsales. Les routes se composent de deux parties : une méthode HTTP et un chemin de ressource (, par exemple, GET /pets. Vous pouvez définir des méthodes HTTP spécifiques pour votre route. Vous pouvez également utiliser la méthode ANY pour faire correspondre toutes les méthodes que vous n’avez pas définies pour une ressource. Vous pouvez créer une route $default qui agit comme un fourre-tout pour les demandes qui ne correspondent à aucune autre route.
Note
API Gateway décode les paramètres de demande encodés par URL avant de les transmettre à votre intégration backend.
Utilisation des variables de chemin
Vous pouvez utiliser des variables de chemin dans les routes des API HTTP.
Par exemple, la route GET /pets/{petID} attrape une demande GET qu’un client soumet à https://. api-id.execute-api.us-east-2.amazonaws.com/pets/6
Une variable de chemin gourmande capture toutes les ressources enfants d’une route. Pour créer une variable de chemin gourmande, ajoutez + au nom de la variable ({proxy+}, par exemple). La variable de chemin gourmande doit se trouver à la fin du chemin de ressource.
Utilisation des paramètres de chaîne de requête
Par défaut, API Gateway envoie les paramètres de chaîne de requête à votre intégration backend s’ils sont inclus dans une demande adressée à une API HTTP.
Par exemple, lorsqu’un client envoie une demande à https://, les paramètres de chaîne de requête api-id.execute-api.us-east-2.amazonaws.com/pets?id=4&type=dog?id=4&type=dog sont envoyés à votre intégration.
Utilisation de la route $default
La route $default attrape les demandes qui ne correspondent pas explicitement aux autres routes de votre API.
Lorsque la route $default reçoit une demande, API Gateway envoie le chemin de demande complet à l’intégration. Par exemple, vous pouvez créer une API avec seulement une route $default et l’intégrer à la méthode ANY avec le point de terminaison HTTP https://petstore-demo-endpoint.execute-api.com. Lorsque vous envoyez une demande à https://, API Gateway envoie une demande à api-id.execute-api.us-east-2.amazonaws.com/store/checkouthttps://petstore-demo-endpoint.execute-api.com/store/checkout.
Pour en savoir plus sur les intégrations HTTP, consultez Création d’intégrations de proxy HTTP pour les API HTTP.
Routage des demandes d’API
Lorsqu’un client envoie une demande d’API, API Gateway détermine d’abord à quelle étape doit être acheminée la demande. Si la demande correspond explicitement à une étape, API Gateway envoie la demande à cette dernière. Si aucune étape ne correspond entièrement à la demande, API Gateway envoie la demande à l’étape $default. S’il n’y a pas d’étape $default, l’API renvoie {"message":"Not
Found"} et ne génère pas de journaux CloudWatch.
Après avoir sélectionné une étape, API Gateway sélectionne une route. API Gateway sélectionne la route avec la correspondance la plus spécifique, en utilisant les priorités suivantes :
Correspondance complète pour une route et une méthode.
Correspondance pour une route et une méthode avec une variable de chemin gourmande (
{proxy+}).La route
$default
Si aucune route ne correspond à une demande, API Gateway retourne {"message":"Not Found"} au client.
Par exemple, examinez une API avec une étape $default et les exemples de routes suivants :
GET /pets/dog/1GET /pets/dog/{id}GET /pets/{proxy+}ANY /{proxy+}$defaultLe tableau suivant résume la façon dont API Gateway achemine les demandes vers les routes de l’exemple.
| Requête | Route sélectionnée | Explication |
|---|---|---|
|
|
|
La demande correspond entièrement à cette route statique. |
|
|
|
La demande correspond entièrement à cette route. |
|
|
|
La demande ne correspond pas entièrement à une route. La route avec une méthode |
|
|
La méthode |
