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.
Règles de routage pour connecter les étapes de l'API à un nom de domaine personnalisé pour REST APIs
Une règle de routage est un ensemble de conditions qui invoquent une action lorsqu’elles sont réunies. Par exemple, une règle peut acheminer une demande entrante d’un nom de domaine personnalisé qui contient l’en-tête Hello:World et le chemin de base users vers l’étape production d’une API REST.
Les règles sont évaluées par ordre de priorité. Si vous définissez le mode de routage sur ROUTING_RULE_THEN_API_MAPPING, API Gateway évalue toujours toutes les règles de routage avant de passer aux mappages d’API. La liste suivante décrit les conditions, les actions et les priorités d’une règle de routage.
- Conditions
-
Lorsque les conditions d'une règle sont satisfaites, ses actions sont effectuées. API Gateway prend en charge jusqu’à deux conditions d’en-tête et une condition de chemin. API Gateway évalue conjointement les conditions d’en-tête et les conditions de chemin de base.
Vous pouvez créer une règle sans condition. Lorsqu’API Gateway évalue cette règle, l’action est toujours exécutée. Vous pouvez créer une règle sans condition comme règle fourre-tout.
Pour plus d’informations sur les conditions d’en-tête, consultez Correspondance des conditions d’en-tête. Pour plus d’informations sur les conditions de chemin, consultez Correspondance des conditions de chemin de base.
- Actions
-
Les actions sont le résultat de la correspondance entre les conditions et la règle de routage. Actuellement, la seule action prise en charge consiste à invoquer une étape d’une API REST.
Chaque règle peut comporter une action.
- Priority
-
La priorité détermine l’ordre d’évaluation des règles, de la valeur la plus basse à la valeur la plus élevée. Les règles ne peuvent pas avoir la même priorité.
Vous pouvez définir la priorité entre 1 et 1 000 000. Si une règle a une priorité de 1, API Gateway l’évalue en premier. Lorsque vous créez une règle, nous vous recommandons d’ajouter des espaces entre les priorités. Vous pourrez ainsi modifier la priorité des règles et en ajouter de nouvelles. Pour de plus amples informations, veuillez consulter Modification de la priorité d’une règle de routage.
Pour voir des exemples d’évaluation des règles de routage par API Gateway, consultez Exemples d’évaluation de règles de routage par API Gateway.
Types de conditions des règles de routage API Gateway
La section suivante décrit les types de conditions des règles de routage. API Gateway applique une règle que si toutes les conditions sont réunies.
Correspondance des conditions d’en-tête
Lorsque vous créez une condition d’en-tête, vous pouvez faire correspondre le nom de l’en-tête et la valeur globale de l’en-tête, par exemple Hello:World. API Gateway utilise une correspondance littérale pour valider les conditions de correspondance des en-têtes. Votre condition peut utiliser jusqu’à deux en-têtes, séparés par AND. Par exemple, votre condition peut être remplie si une demande entrante comprend Hello:World et x-version:beta.
La correspondance du nom de l’en-tête n’est pas sensible à la casse, mais la valeur globale de l’en-tête l’est. Hello:World correspond à hello:World, mais pas Hello:world.
Pour connaître la liste des valeurs d’en-tête restreintes, consultez Restrictions.
Utilisation de caractères génériques avec des conditions d’en-tête
Les caractères génériques ne peuvent être utilisés que dans la valeur globale de l’en-tête, et doivent être *prefix-match, suffix-match* ou *contains*. Le tableau suivant présente des exemples d’utilisation des caractères génériques pour la correspondance des conditions d’en-tête.
| Conditions d’en-tête | Demandes conformes à la règle de routage | Demandes non conformes à la règle de routage |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Aucune |
Si vous créez des conditions pour plusieurs valeurs d’en-tête, par exemple Accept:application/json,text/xml, nous vous recommandons d’utiliser *contains* pour vos conditions d’en-tête et d’éviter de créer des conditions à l’aide de la virgule (,).
Étant donné qu’API Gateway fait correspondre littéralement les conditions d’en-tête, les correspondances sémantiques peuvent être acheminées différemment. Le tableau suivant montre les différence de résultat des règles de routage.
| Conditions d’en-tête | Demandes conformes à la règle de routage | Demandes non conformes à la règle de routage |
|---|---|---|
|
|
|
|
|
|
|
Aucune |
Correspondance des conditions de chemin de base
Lorsque vous créez une condition de chemin de base, si la demande entrante contient le chemin que vous avez spécifié, la règle correspond. La correspondance étant sensible à la casse, le chemin New/Users ne correspondra pas à new/users.
Vous ne pouvez créer une condition de chemin de base que pour un seul chemin de base.
Pour obtenir la liste des restrictions des conditions de chemin de base, consultez Restrictions.
Suppression du chemin de base avec les conditions du chemin de base
Lorsque vous créez une condition de trajectoire de base, vous pouvez choisir de supprimer la trajectoire de base. Lorsque vous supprimez le chemin de base, API Gateway supprime le chemin de base entrant correspondant lorsqu’il invoque l’API cible. C’est le même comportement que lorsque vous utilisez un mappage d’API. Si vous ne supprimez pas le chemin de base, API Gateway transmet l’intégralité du chemin de base à l’API cible. Nous vous recommandons de supprimer le chemin de base uniquement lorsque vous recréez un mappage d’API.
Le tableau suivant présente des exemples d’évaluation de la condition de suppression du chemin de base par API Gateway.
| Condition | Suppression du chemin de base | Demande entrante | Résultat |
|---|---|---|---|
|
Si le chemin de base contient |
True |
|
API Gateway appelle la méthode |
|
Si le chemin de base contient |
False |
|
API Gateway appelle la méthode |
|
Si le chemin de base contient |
True |
|
API Gateway appelle la méthode |
|
Si le chemin de base contient |
False |
|
API Gateway appelle la méthode |
|
Si le chemin de base contient |
True |
|
API Gateway appelle la méthode |
|
Si le chemin de base contient |
False |
|
API Gateway appelle la méthode |
Restrictions
-
L'API cible et le nom de domaine personnalisé doivent se trouver dans le même AWS compte.
Chaque règle peut comporter une API cible.
-
Pour un nom de domaine personnalisé privé, vous ne pouvez créer une règle de routage que vers une API privée. Pour un nom de domaine personnalisé public, vous ne pouvez créer une règle de routage que vers une API publique. Vous ne pouvez pas mélanger des ressources publiques et privées.
-
Si votre nom de domaine personnalisé comporte des mappages d'API à la fois vers REST et HTTP APIs, les règles de routage ne sont pas prises en charge.
La priorité maximale est de 1 000 000.
-
Restrictions applicables aux en-têtes :
Chaque condition
anyOfne peut contenir qu’une seule valeur d’en-tête.-
Les seuls caractères autorisés pour les noms d’en-tête et les valeurs globales des en-têtes sont spécifiés par RFC 7230
, à savoir a-z,A-Z,0-9et les caractères spéciaux suivants :*?-!#$%&'.^_`|~. -
Vous pouvez utiliser un caractère générique dans la valeur globale de l’en-tête, mais celui-ci doit être
*prefix-match,suffix-match*ou*contains*. Vous ne pouvez pas utiliser*au milieu d’une valeur globale d’en-tête. Les noms d’en-tête génériques ne sont pas pris en charge.
Le nom de l’en-tête doit contenir moins de 40 caractères.
La valeur globale de l’en-tête doit être inférieure à 128 caractères.
La valeur globale de l’en-tête pour une correspondance infixe doit être inférieure à 40 caractères.
Les en-têtes suivants ne sont pas pris en charge en tant que conditions :
access-control-*apigw-*AuthorizationConnectionContent-EncodingContent-LengthContent-LocationForwardedKeep-AliveOriginProxy-AuthenticateProxy-AuthorizationTETrailersTransfer-EncodingUpgradex-amz-*x-amzn-*x-apigw-api-idX-Forwarded-ForX-Forwarded-HostX-Forwarded-Protox-restAPIVia
-
Restrictions applicables aux chemins de base :
Le nom du chemin de base doit contenir moins de 128 caractères.
-
Le chemin de base ne doit contenir que des lettres, des chiffres et les caractères suivants :
$-_.+!*'()/.Ces caractères ne sont pas pris en charge pour les expressions régulières.
Le chemin de base ne peut ni commencer ni se terminer par une barre oblique inversée (
\).
