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.
# Publication d’API WebSocket invocables par les clients
Le simple fait de créer et le développer une API API Gateway ne la rend pas automatiquement appelable par vos utilisateurs. Pour la rendre appelable, vous devez déployer votre API dans une étape. En outre, vous pouvez personnaliser l’URL que vos utilisateurs utiliseront pour accéder à votre API. Vous pouvez lui attribuer un domaine cohérent avec votre marque ou plus facilement mémorisable que l’URL par défaut de votre API.
Dans cette section, vous pouvez apprendre à déployer votre API et à personnaliser l’URL que vous fournissez aux utilisateurs pour y accéder.
**Note**
Pour renforcer la sécurité de vos API API Gateway, le domaine `execute-api.{region}.amazonaws.com` est enregistré dans la [liste des suffixes publics (PSL](https://publicsuffix.org/)). Pour plus de sécurité, nous vous recommandons d’utiliser des cookies avec un préfixe `__Host-` si vous devez définir des cookies sensibles dans le nom de domaine par défaut de vos API API Gateway. Cette pratique vous aidera à protéger votre domaine contre les tentatives de falsification de requêtes intersites (CSRF). Pour plus d’informations, consultez la page [Set-Cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes) du Mozilla Developer Network.
**Topics**
+ [Création d'étapes pour WebSocket APIs in API Gateway](websocket-api-stages.md)
+ [Déploiement WebSocket APIs dans API Gateway](apigateway-set-up-websocket-deployment.md)
+ [Politique de sécurité pour WebSocket APIs in API Gateway](websocket-api-ciphers.md)
+ [Noms de domaine personnalisés pour les API WebSocket dans API Gateway](websocket-api-custom-domain-names.md)
# Création d'étapes pour WebSocket APIs in API Gateway
Une étape d’API est une référence logique à un état du cycle de vie de votre API (par exemple, `dev`, `prod`, `beta` ou `v2`). Les étapes API sont identifiées par leur ID d’API et leur nom d’étape, et elles sont incluses dans l’URL que vous utilisez pour appeler l’API. Chaque étape est une référence nommée à un déploiement de l’API et elle est mise à la disposition des applications clientes à appeler.
Un déploiement est un instantané de la configuration de votre API. Après que vous avez déployé une API dans une étape, les clients peuvent l’appeler. Vous devez déployer une API pour que les modifications prennent effet.
## Variables d’étape
Les variables d'étape sont des paires clé-valeur que vous pouvez définir pour une étape d'une WebSocket API. Elles se comportent comme les variables d’environnement et peuvent être utilisées dans votre configuration d’API.
Par exemple, vous pouvez définir une variable d’étape, puis définir sa valeur en tant que point de terminaison HTTP pour une intégration de proxy HTTP. Par la suite, vous pouvez référencer le point de terminaison à l’aide du nom de la variable d’étape associée. Ce faisant, vous pouvez utiliser la même configuration d’API avec un point de terminaison différent à chaque étape. De même, vous pouvez utiliser des variables d'étape pour spécifier une intégration de AWS Lambda fonction différente pour chaque étape de votre API.
**Note**
Les variables d’étape ne sont pas destinées à être utilisées pour des données sensibles, telles que les informations d’identification. Pour transmettre des données sensibles aux intégrations, utilisez un AWS Lambda autorisateur. Vous pouvez transmettre des données sensibles aux intégrations dans la sortie du mécanisme d’autorisation Lambda. Pour en savoir plus, consultez la section [Format de réponse du mécanisme d’autorisation Lambda](http-api-lambda-authorizer.md#http-api-lambda-authorizer.payload-format-response).
### Exemples
Pour utiliser une variable d’étape afin de personnaliser le point de terminaison d’intégration HTTP, vous devez d’abord définir le nom et la valeur de la variable stage (par exemple, `url`) avec la valeur `example.com`. Ensuite, configurez une intégration de proxy HTTP. Au lieu d’entrer l’URL du point de terminaison, vous pouvez demander à API Gateway d’utiliser la valeur de la variable d’étape, **http://\$1\$1stageVariables.url\$1**. Cette valeur demande à API Gateway de remplacer votre variable d’étape `${}` au moment de l’exécution, en fonction de l’étape à laquelle se trouve votre API.
Vous pouvez référencer les variables d'étape de la même manière pour spécifier un nom de fonction Lambda ou un AWS ARN de rôle.
Lorsque vous spécifiez un nom de fonction Lambda en tant que valeur de variable d’étape, vous devez configurer les autorisations sur cette fonction Lambda manuellement. La commande [add permission](https://docs.aws.amazon.com/cli/latest/reference/lambda/add-permission.html) suivante ajoute les autorisations requises :
```
aws lambda add-permission --function-name arn:aws:lambda:XXXXXX:your-lambda-function-name --source-arn arn:aws:execute-api:us-east-1:YOUR_ACCOUNT_ID:api_id/*/HTTP_METHOD/resource --principal apigateway.amazonaws.com --statement-id apigateway-access --action lambda:InvokeFunction
```
## Référence des variables d’étape API Gateway
### Intégration HTTP URIs
Une variable d’étape peut être utilisée dans une URI d’intégration HTTP, comme illustré dans les exemples suivants.
+ URI complet sans protocole – `http://${stageVariables.}`
+ Domaine complet – `http://${stageVariables.}/resource/operation`
+ Sous-domaine – `http://${stageVariables.}.example.com/resource/operation`
+ Chemin – `http://example.com/${stageVariables.}/bar`
+ Chaîne de requête – `http://example.com/foo?q=${stageVariables.}`
### Fonctions Lambda
Vous pouvez utiliser une variable d’étape à la place d’un nom de fonction Lambda ou d’un alias, comme illustré dans les exemples suivants.
+ `arn:aws:apigateway::lambda:path/2015-03-31/functions/arn:aws:lambda:::function:${stageVariables.}/invocations`
+ `arn:aws:apigateway::lambda:path/2015-03-31/functions/arn:aws:lambda:::function::${stageVariables.}/invocations`
**Note**
Pour utiliser une variable d’étape pour une fonction Lambda, la fonction doit se trouver dans le même compte que l’API. Les variables d’étape ne prennent pas en charge les fonctions Lambda inter-comptes.
### AWS informations d'identification d'intégration
Vous pouvez utiliser une variable d'étape dans le cadre de l'ARN d'identification AWS d'un utilisateur ou d'un rôle, comme illustré dans l'exemple suivant.
+ `arn:aws:iam:::${stageVariables.}`
# Déploiement WebSocket APIs dans API Gateway
Après avoir créé votre WebSocket API, vous devez la déployer pour que vos utilisateurs puissent l'invoquer.
Pour déployer une API, vous devez créer un [déploiement d’API](api-gateway-basic-concept.md#apigateway-definition-api-deployment) et l’associer à une [étape](api-gateway-basic-concept.md#apigateway-definition-api-stage). Chaque étape est un instantané de l’API et peut être appelée par les applications client.
**Important**
Chaque fois que vous mettez à jour une API, vous devez la redéployer. Les modifications apportées à tout autre élément que les paramètres d’étape nécessitent un redéploiement, notamment des modifications des ressources suivantes :
Routes
Intégrations
Mécanismes d’autorisation
Par défaut, vous êtes limité à 10 étapes pour chaque API. Nous recommandons de réutiliser les étapes pour vos déploiements.
Pour appeler une WebSocket API déployée, le client envoie un message à l'URL de l'API. L’URL est déterminée par le nom d’hôte et le nom de l’étape de l’API.
**Note**
API Gateway prend en charge des charges utiles jusqu’à 128 Ko, avec une taille de trame maximale de 32 Ko. Si un message dépasse 32 Ko, il devra être scindé en plusieurs trames, chacune de 32 Ko ou moins.
En utilisant le nom de domaine par défaut de l'API, l'URL (par exemple) d'une WebSocket API dans une étape donnée (`{stageName}`) est au format suivant :
```
wss://{api-id}.execute-api.{region}.amazonaws.com/{stageName}
```
Pour rendre l'URL de l' WebSocket API plus conviviale, vous pouvez créer un nom de domaine personnalisé (par exemple,`api.example.com`) pour remplacer le nom d'hôte par défaut de l'API. Le processus de configuration est le même que pour REST APIs. Pour de plus amples informations, veuillez consulter [Nom de domaine personnalisé pour le REST public APIs dans API Gateway](how-to-custom-domains.md).
Les étapes permettent un contrôle de version solide de votre API. Par exemple, vous pouvez déployer une API dans une étape `test` et une étape `prod`, puis utiliser l’étape `test` comme version de test et l’étape `prod` comme version stable. Une fois que les mises à jour passent le test, vous pouvez migrer l’étape `test` vers l’étape `prod`. La promotion peut être effectuée en redéployant l’API à l’étape `prod`. Pour plus d’informations sur les étapes, consultez [Configuration d’une étape pour une API REST dans API Gateway](set-up-stages.md).
**Topics**
+ [Créez un déploiement d' WebSocket API à l'aide du AWS CLI](#apigateway-create-websocket-deployment-using-awscli)
+ [Création d'un déploiement d' WebSocket API à l'aide de la console API Gateway](#apigateway-create-websocket-deployment-using-console)
## Créez un déploiement d' WebSocket API à l'aide du AWS CLI
La commande [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-deployment.html) suivante crée un déploiement :
```
aws apigatewayv2 --region us-east-1 create-deployment --api-id aabbccddee
```
Le résultat se présente comme suit :
```
{
"DeploymentId": "fedcba",
"DeploymentStatus": "DEPLOYED",
"CreatedDate": "2018-11-15T06:49:09Z"
}
```
L’API déployée ne peut pas être appelée tant que vous n’associez pas le déploiement à une étape. Vous pouvez créer une nouvelle étape ou réutiliser une étape créée précédemment.
La commande [create-stage](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-stage.html) suivante crée une étape et l’associe au déploiement :
```
aws apigatewayv2 --region us-east-1 create-stage --api-id aabbccddee --deployment-id fedcba --stage-name test
```
Le résultat se présente comme suit :
```
{
"StageName": "test",
"CreatedDate": "2018-11-15T06:50:28Z",
"DeploymentId": "fedcba",
"DefaultRouteSettings": {
"MetricsEnabled": false,
"ThrottlingBurstLimit": 5000,
"DataTraceEnabled": false,
"ThrottlingRateLimit": 10000.0
},
"LastUpdatedDate": "2018-11-15T06:50:28Z",
"StageVariables": {},
"RouteSettings": {}
}
```
Vous pouvez également réutiliser une étape existante en mettant à jour la `deploymentId` propriété de l'étape avec le nouvel ID de déploiement (*deployment-id*). La commande [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-stage.html) suivante met à jour l’ID de déploiement de l’étape :
```
aws apigatewayv2 update-stage --region region \
--api-id api-id \
--stage-name stage-name \
--deployment-id deployment-id
```
## Création d'un déploiement d' WebSocket API à l'aide de la console API Gateway
Pour utiliser la console API Gateway afin de créer un déploiement pour une WebSocket API :
1. Connectez-vous à la console API Gateway et choisissez l’API.
1. Sélectionnez **Deploy API (Déployer une API)**.
1. Choisissez l’étape souhaitée dans la liste déroulante ou saisissez le nom d’une nouvelle étape.
# Politique de sécurité pour WebSocket APIs in API Gateway
API Gateway applique une politique de sécurité `TLS_1_2` pour tous les points de terminaison de WebSocket l'API.
Une *politique de sécurité* est une combinaison prédéfinie d’une version minimale du protocole TLS et de suites de chiffrement offerte par Amazon API Gateway. Le protocole TLS résout les problèmes de sécurité de réseau tels que la falsification et le risque d’écoute illicite entre un client et un serveur. Lorsque vos clients établissent une liaison TLS vers votre API via le domaine personnalisé, la politique de sécurité applique les options de version TLS et de suite de chiffrement que vos clients peuvent choisir d’utiliser. Cette politique de sécurité accepte le trafic TLS 1.2 et TLS 1.3 et rejette le trafic TLS 1.0.
## Protocoles et chiffrements TLS pris en charge pour WebSocket APIs
Le tableau suivant décrit les protocoles TLS pris en charge pour WebSocket APIs.
| **Protocoles TLS** | **Politique de sécurité TLS\$11\$12** |
| --- | --- |
| TLSv13. | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| TLSv12. | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
Le tableau suivant décrit les chiffrements TLS disponibles pour la politique de sécurité TLS 1\$12 pour. WebSocket APIs
| **Chiffrements TLS** | **Politique de sécurité TLS\$11\$12** |
| --- | --- |
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| ECDHE-ECDSA- -GCM- AES128 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| ECDHE-RSA- -GCM- AES128 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| ECDHE-ECDSA- - AES128 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| ECDHE-RSA- - AES128 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| ECDHE-ECDSA- -GCM- AES256 SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| ECDHE-RSA- -GCM- AES256 SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| ECDHE-ECDSA- - AES256 SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| ECDHE-RSA- - AES256 SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| AES128-GCM- SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| AES128-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| AES256-GCM- SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
| AES256-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/success_icon.svg) Oui |
## Noms de chiffrement OpenSSL et RFC
OpenSSL et IETF RFC 5246 utilisent des noms différents pour les mêmes chiffrements. Pour obtenir la liste des noms de chiffrement, consultez [Noms de chiffrement OpenSSL et RFC](apigateway-security-policies-list.md#apigateway-secure-connections-openssl-rfc-cipher-names).
## Informations sur REST APIs et HTTP APIs
Pour plus d'informations sur REST APIs et HTTP APIs, consultez [Choisissez une politique de sécurité pour votre domaine personnalisé dans API Gateway](apigateway-custom-domain-tls-version.md) et[Politique de sécurité pour le protocole HTTP APIs dans API Gateway](http-api-ciphers.md).
# Noms de domaine personnalisés pour les API WebSocket dans API Gateway
Les *noms de domaine personnalisés* sont des URL plus simples et plus intuitives que vous pouvez fournir à vos utilisateurs d’API.
Après avoir déployé votre API, vous (et vos clients) pouvez appeler cette API à l’aide de l’URL de base par défaut au format suivant :
```
https://api-id.execute-api.region.amazonaws.com/stage
```
où *api-id* est généré par API Gateway, *region* est la région AWS et *stage* est spécifié par vous lors du déploiement de l’API.
La partie nom d’hôte de l’URL, `api-id.execute-api.region.amazonaws.com`, fait référence à un point de terminaison de l’API. Le nom par défaut du point de terminaison de l’API est généré de manière aléatoire, difficile à mémoriser et peu convivial.
Avec des noms de domaine personnalisés, vous pouvez configurer le nom d’hôte de votre API et choisir un chemin de base (par exemple, `myservice`) pour mapper l’URL alternative à votre API. Par exemple, une URL de base de l’API plus conviviale peut devenir :
```
https://api.example.com/myservice
```
## Considérations
Les considérations suivantes peuvent avoir une incidence sur votre utilisation d’un nom de domaine personnalisé.
+ Si vous mappez un nom de domaine personnalisé à une API WebSocket, vous ne pouvez pas le mapper à une API REST ou à une API HTTP.
+ Seuls les noms de domaine personnalisés régionaux sont pris en charge.
+ Pour la version TLS minimale, seule la version TLS 1.2 est prise en charge.
+ Vous devez créer ou mettre à jour l’enregistrement de ressource de votre fournisseur DNS pour le mapper au point de terminaison de votre API. Sans ce mappage, les demandes d’API destinées au nom de domaine personnalisé ne peuvent pas atteindre API Gateway.
+ Vous pouvez prendre en charge un nombre presque infini de noms de domaine sans dépasser le quota par défaut en utilisant un certificat générique. Pour de plus amples informations, consultez [Noms de domaine personnalisés génériques](http-api-custom-domain-names.md#http-wildcard-custom-domain-names).
## Prérequis
Les conditions suivantes sont requises pour créer un nom de domaine personnalisé.
### Enregistrement d’un nom de domaine
Pour pouvoir configurer des noms de domaine personnalisés pour vos API, vous devez avoir enregistré un nom de domaine Internet. Vous pouvez enregistrer votre nom de domaine Internet avec [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) ou utiliser un bureau d’enregistrement de domaine tiers de votre choix. Votre nom de domaine personnalisé peut être le nom d’un sous-domaine ou le domaine racine (également nommé « zone apex ») d’un domaine Internet enregistré.
Votre nom de domaine doit respecter la spécification [RFC 1035](https://tools.ietf.org/html/rfc1035#section-2.3.4) et peut comporter un maximum de 63 octets par étiquette et 255 octets au total.
### Certificats pour les noms de domaine personnalisés
Avant de configurer un nom de domaine personnalisé pour une API, vous devez avoir un certificat SSL/TLS prêt dans ACM. Si ACM n’est pas disponible dans la région AWS où vous créez votre nom de domaine personnalisé, vous devez importer un certificat dans API Gateway dans cette région.
Pour importer un certificat SSL/TLS, vous devez fournir le corps du certificat SSL/TLS au format PEM, sa clé privée, ainsi que la chaîne de certificats du nom de domaine personnalisé.
Chaque certificat stocké dans ACM est identifié par son ARN. Avec les certificats émis par ACM, vous n’avez pas à vous inquiéter d’une éventuelle exposition des informations sensibles du certificat, par exemple sa clé privée. Pour utiliser un certificat géré par AWS pour un nom de domaine, indiquez simplement son ARN.
Si votre application utilise l’épinglage de certificat, parfois appelé épinglage SSL, pour épingler un certificat ACM, l’application ne pourra peut-être pas se connecter à votre domaine une fois qu’AWS aura renouvelé le certificat. Pour plus d’informations, consultez la section [Problèmes d’épinglage de certificat](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-pinning.html) dans le *Guide de l’utilisateur AWS Certificate Manager*.
## Noms de domaine personnalisés génériques
Avec les noms de domaine personnalisés génériques, vous pouvez prendre en charge un nombre presque infini de noms de domaine sans dépasser le [quota par défaut](limits.md). Par exemple, vous pouvez donner à chacun de vos clients son propre nom de domaine, `customername.api.example.com`.
Pour créer un nom de domaine personnalisé générique, vous pouvez spécifier un caractère générique (`*`) comme premier sous-domaine d’un domaine personnalisé qui représente tous les sous-domaines possibles d’un domaine racine.
Par exemple, le nom de domaine personnalisé générique `*.example.com` se traduit par des sous-domaines tels que `a.example.com`, `b.example.com` et `c.example.com`, qui effectuent tous un routage vers le même domaine.
Les noms de domaine personnalisés génériques prennent en charge des configurations distinctes des noms de domaine personnalisés standard d’API Gateway. Par exemple, dans un seul compte AWS, vous pouvez configurer `*.example.com` et `a.example.com` pour qu’ils se comportent différemment.
Vous pouvez utiliser les variables de contexte `$context.domainName` et `$context.domainPrefix` pour déterminer le nom de domaine utilisé par un client pour appeler votre API. Pour en savoir plus sur les variables de contexte, consultez [Variables pour les transformations de données pour API Gateway](api-gateway-mapping-template-reference.md).
Pour créer un nom de domaine personnalisé générique, vous devez fournir un certificat émis par ACM qui a été validé à l’aide du DNS ou de la méthode de validation par e-mail.
**Note**
Vous ne pouvez pas créer un nom de domaine personnalisé générique si un autre compte AWS a créé un nom de domaine personnalisé en conflit avec ce nom. Par exemple, si le compte A a créé `a.example.com`, le compte B ne peut pas créer le nom de domaine personnalisé générique `*.example.com`.
Si les comptes A et B ont le même propriétaire, vous pouvez contacter le [AWSCentre de support](https://console.aws.amazon.com/support/home#/) pour demander une exception.
## Étapes suivantes pour les noms de domaine personnalisés
Pour configurer un nom de domaine personnalisé pour une API HTTP, utilisez la documentation de la section API REST du Guide du développeur API Gateway.
D’abord, spécifiez un certificat pour votre nom de domaine personnalisé. Pour de plus amples informations, consultez [Préparez les certificats dans AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md). Ensuite, créez un nom de domaine personnalisé régional. Pour de plus amples informations, consultez [Configuration d’un nom de domaine personnalisé régional dans API Gateway](apigateway-regional-api-custom-domain-create.md).
# Mappage des étapes d’API à un nom de domaine personnalisé pour les API WebSocket
Les mappages d’API vous permettent de connecter des étapes d’API à un nom de domaine personnalisé. Après avoir créé un nom de domaine et configuré les enregistrements DNS, vous pouvez utiliser les mappages d’API pour envoyer le trafic vers vos API via votre nom de domaine personnalisé.
Un mappage d’API spécifie une API, une étape et éventuellement un chemin à utiliser pour le mappage. Par exemple, vous pouvez mapper l’étape `production` d’une API à `wss://api.example.com/orders`.
Avant de créer un mappage d’API, vous devez disposer d’une API, d’une étape et d’un nom de domaine personnalisé. Pour plus d’informations sur la création d’un nom de domaine personnalisé, consultez [Configuration d’un nom de domaine personnalisé régional dans API Gateway](apigateway-regional-api-custom-domain-create.md).
## Restrictions
+ Dans un mappage d’API, le nom de domaine personnalisé et les API mappées doivent se trouver sur le même compte AWS.
+ Les mappages d’API ne doivent contenir que des lettres, des chiffres et les caractères suivants : `$-_.+!*'()`.
+ La longueur maximale du chemin d’un mappage d’API est de 300 caractères.
+ Vous ne pouvez pas mapper les API WebSocket au même nom de domaine personnalisé qu’une API HTTP ou une API REST.
+ Si vous créez un mappage d’API à plusieurs niveaux, API Gateway convertit tous les noms d’en-tête en minuscules.
## Création d’un mappage d’API
Pour créer un mappage d’API, vous devez d’abord créer un nom de domaine personnalisé, une API et une étape. Pour plus d’informations sur la création d’un nom de domaine personnalisé, consultez [Configuration d’un nom de domaine personnalisé régional dans API Gateway](apigateway-regional-api-custom-domain-create.md).
------
#### [ AWS Management Console ]
**Pour créer un mappage d’API**
1. Connectez-vous à la console API Gateway à l’adresse : [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Choisissez **Noms de domaine personnalisés**.
1. Sélectionnez un nom de domaine personnalisé que vous avez déjà créé.
1. Choisissez **Mappages d’API**.
1. Choisissez **Configurer les mappages d’API**.
1. Choisissez **Ajouter un nouveau mappage**.
1. Entrez une **API**, une **Étape** et, éventuellement, un **Chemin d’accès**.
1. Choisissez **Save (Enregistrer)**.
------
#### [ AWS CLI ]
La commande [create-api-mapping](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api-mapping.html) suivante crée un mappage d’API. Dans cet exemple, API Gateway envoie des demandes `api.example.com/v1` à l’API et à l’étape spécifiés.
```
aws apigatewayv2 create-api-mapping \
--domain-name api.example.com \
--api-mapping-key v1 \
--api-id a1b2c3d4 \
--stage test
```
------
#### [ CloudFormation ]
L’exemple CloudFormation suivant crée un mappage d’API.
```
MyApiMapping:
Type: 'AWS::ApiGatewayV2::ApiMapping'
Properties:
DomainName: api.example.com
ApiMappingKey: 'v1'
ApiId: !Ref MyApi
Stage: !Ref MyStage
```
------
# Types d’adresses IP des noms de domaine personnalisés pour les API WebSocket
Lorsque vous créez un domaine personnalisé, vous devez spécifier le type d’adresse IP pouvant invoquer votre domaine. Vous avez le choix entre IPv4 (pour autoriser les adresses IPv4 à invoquer votre domaine) et Dualstack (pour autoriser les adresses IPv4 et IPv6 à invoquer votre domaine). Nous vous recommandons de définir le type d’adresse IP sur Dualstack pour éviter l’épuisement de l’espace IP ou renforcer votre niveau de sécurité. Pour plus d’informations sur les avantages d’un type d’adresse IP à double pile, consultez [IPv6 sur AWS](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/internet-protocol-version-6.html).
## Considérations relatives aux types d’adresses IP
Les considérations suivantes peuvent avoir une incidence sur votre utilisation des types d’adresses IP.
+ Le type d’adresse IP par défaut des noms de domaine personnalisés API Gateway est IPv4.
+ Il n’est pas nécessaire que votre nom de domaine personnalisé possède le même type d’adresse IP pour toutes les API qui y sont mappées. La désactivation du point de terminaison de votre API par défaut peut avoir une incidence sur la manière dont les appelants peuvent invoquer votre API.
## Modification du type d’adresse IP d’un nom de domaine personnalisé
Vous pouvez modifier le type d’adresse IP en mettant à jour la configuration de point de terminaison du nom de domaine. Vous pouvez mettre à jour la configuration du point de terminaison à l’aide de la AWS Management Console, de l’AWS CLI, d’CloudFormation ou d’un kit SDK AWS.
------
#### [ AWS Management Console ]
**Pour modifier le type d’adresse IP d’un nom de domaine personnalisé**
1. Connectez-vous à la console API Gateway à l’adresse : [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Choisissez un nom de domaine personnalisé public.
1. Sélectionnez **Configuration du point de terminaison**.
1. Pour Type d’adresse IP, choisissez **IPv4** ou **Dualstack**.
1. Choisissez **Save (Enregistrer)**.
------
#### [ AWS CLI ]
La commande [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html) suivante met à jour une API pour qu’elle possède le type d’adresse IP Dualstack :
```
aws apigatewayv2 update-domain-name \
--domain-name dualstack.example.com \
--domain-name-configurations CertificateArn=arn:aws:acm:us-east-1:111122223333:certificate/abcd1234-5678-abc,IpAddressType=dualstack
```
Le résultat se présente comme suit :
```
{
"ApiMappingSelectionExpression": "$request.basepath",
"DomainName": "dualstack.example.com",
"DomainNameConfigurations": [
{
"ApiGatewayDomainName": "d-abcd1234.execute-api.us-east-1.amazonaws.com",
"CertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/abcd1234-5678-abc",
"DomainNameStatus": "AVAILABLE",
"EndpointType": "REGIONAL",
"HostedZoneId": "Z3LQWSYCGH4ADY",
"SecurityPolicy": "TLS_1_2",
"IpAddressType": "dualstack"
}
],
"Tags": {}
}
```
------
# Désactiver le point de terminaison par défaut pour WebSocket APIs
Par défaut, les clients peuvent appeler votre API en utilisant le point de terminaison `execute-api` généré par API Gateway pour votre API. Pour vous assurer que les clients peuvent accéder à votre API en utilisant uniquement un nom de domaine personnalisé, désactivez le point de terminaison par défaut `execute-api`. Lorsque vous désactivez le point de terminaison par défaut, toutes les étapes d’une API sont affectées.
La procédure suivante montre comment désactiver le point de terminaison par défaut pour une WebSocket API.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Choisissez une WebSocket API.
1. Choisissez **Paramètres de l’API**.
1. Dans l’onglet **Détails de l’API**, choisissez **Modifier**.
1. Pour **Point de terminaison par défaut**, sélectionnez **Inactif**.
1. Sélectionnez **Enregistrer les modifications**.
1. Dans le volet de navigation principal, sélectionnez **Routes**.
1. Choisissez **Déployer**, puis redéployez votre API ou créez une étape pour que la modification prenne effet.
------
#### [ AWS CLI ]
La commande [update-api](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-api.html) suivante désactive le point de terminaison par défaut d'une API : WebSocket
```
aws apigatewayv2 update-api \
--api-id abcdef123 \
--disable-execute-api-endpoint
```
Après avoir désactivé le point de terminaison par défaut, vous devez déployer votre API pour que la modification prenne effet.
La AWS CLI commande suivante crée un déploiement.
```
aws apigatewayv2 create-deployment \
--api-id abcdef123 \
--stage-name dev
```
------