# Publicar APIs de WebSocket para os clientes invocarem
Apenas criar e desenvolver uma API do API Gateway não fará com que ela possa ser chamada automaticamente pelos usuários. Para que ela possa ser chamada, implante a API em um estágio. Além disso, você pode querer personalizar o URL que os usuários usarão para acessar a API. Você pode dar a ele um domínio que seja consistente com sua marca ou que seja mais memorável que o URL padrão da API.
Nesta seção, você pode aprender a implantar a API e personalizar o URL fornecido aos usuários para acessá-la.
**nota**
Para aumentar a segurança das APIs do API Gateway, o domínio `execute-api.{region}.amazonaws.com` é registrado na [Public Suffix List (PSL)](https://publicsuffix.org/). Para maior segurança, recomendamos que você use cookies com um prefixo `__Host-` se precisar definir cookies confidenciais no nome de domínio padrão para as APIs do API Gateway. Essa prática ajudará a defender seu domínio contra tentativas de falsificação de solicitação entre sites (CSRF). Para obter mais informações, consulte a página [Set-Cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes) na Mozilla Developer Network.
**Topics**
+ [Criar estágios para APIs de WebSocket no API Gateway](websocket-api-stages.md)
+ [Implantar APIs de WebSocket no API Gateway](apigateway-set-up-websocket-deployment.md)
+ [Política de segurança para APIs de WebSocket no API Gateway](websocket-api-ciphers.md)
+ [Nomes de domínio personalizados para APIs de WebSocket no API Gateway](websocket-api-custom-domain-names.md)
# Criar estágios para APIs de WebSocket no API Gateway
O estágio de uma API é uma referência lógica a um estado do ciclo de vida de sua API (por exemplo, `dev`, `prod`, `beta` ou `v2`). Os estágios de API são identificados por seu ID de API e nome de estágio e são incluídos no URL que você usa para chamar a API. Cada estágio é uma referência nomeada a uma implantação da API e é disponibilizado para chamadas feitas por aplicativos cliente.
Uma implantação é um instantâneo da configuração da API. Depois de implantar uma API em um estágio, ela estará disponível para ser chamada por clientes. Você deve implantar uma API para que as alterações entrem em vigor.
## Variáveis de estágio
As variáveis de estágio são pares chave-valor que você pode definir para um estágio de uma API WebSocket. Elas atuam como variáveis de ambiente e podem ser usadas na configuração da API.
Por exemplo, você pode definir uma variável de estágio e, depois, definir seu valor como um endpoint HTTP para uma integração de proxy HTTP. Posteriormente, você pode fazer referência ao endpoint usando o nome da variável de estágio associada. Fazendo isso, você pode usar a mesma configuração de API com um endpoint diferente em cada estágio. Da mesma forma, você pode usar variáveis de estágio para especificar uma integração de função diferente do AWS Lambda para cada estágio da API.
**nota**
As variáveis de estágio não se destinam a ser usadas para dados confidenciais, como credenciais. Para transmitir dados confidenciais para integrações, use um autorizador do AWS Lambda. Você pode passar dados confidenciais para integrações na saída do autorizador do Lambda. Para saber mais, consulte [Formato de resposta do autorizador do Lambda](http-api-lambda-authorizer.md#http-api-lambda-authorizer.payload-format-response).
### Exemplos
Para usar uma variável de estágio para personalizar o endpoint de integração HTTP, primeiro defina o nome e o valor da variável de estágio (por exemplo, `url`) com um valor de `example.com`. Depois, configure uma integração de proxy HTTP. Em vez de inserir o URL do endpoint, você pode instruir o API Gateway a usar o valor da variável de estágio, **http://\$1\$1stageVariables.url\$1**. Esse valor instrui o API Gateway a substituir sua variável de estágio `${}` em tempo de execução, dependendo do estágio da API.
É possível fazer referência a variáveis de estágio de forma semelhante para especificar um nome de função do Lambda ou um ARN de função da AWS.
Ao especificar um nome de função do Lambda como um valor de variável de estágio, você deve configurar as permissões nessa função do Lambda manualmente. O comando [add-permission](https://docs.aws.amazon.com/cli/latest/reference/lambda/add-permission.html) indicado abaixo adiciona as permissões necessárias:
```
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
```
## Referência de variáveis de estágio do API Gateway
### URIs de integração HTTP
Uma variável de estágio pode ser usada como parte de um URI de integração HTTP, como mostram os exemplos a seguir.
+ Um URI completo sem protocol – `http://${stageVariables.}`
+ Um domínio complet – `http://${stageVariables.}/resource/operation`
+ Um subdomíni – `http://${stageVariables.}.example.com/resource/operation`
+ Um caminh – `http://example.com/${stageVariables.}/bar`
+ Uma string de consult – `http://example.com/foo?q=${stageVariables.}`
### Funções do Lambda
É possível usar uma variável de estágio no lugar de um nome de função ou alias do Lambda, conforme mostrado nos exemplos a seguir.
+ `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`
**nota**
Para usar uma variável de estágio para uma função do Lambda, a função deve estar na mesma conta que a API. As variáveis de estágio não suportam funções do Lambda entre contas.
### AWSCredenciais de integração da
É possível usar uma variável de estágio como parte de um ARN de credencial de usuário ou de função da AWS, conforme mostrado no exemplo a seguir.
+ `arn:aws:iam:::${stageVariables.}`
# Implantar APIs de WebSocket no API Gateway
Depois de criar sua API WebSocket, você deve implantá-la para permitir que seja invocada por seus usuários após a disponibilização.
Para implantar uma API, você cria uma [implantação da API](api-gateway-basic-concept.md#apigateway-definition-api-deployment) e a associa a um [estágio](api-gateway-basic-concept.md#apigateway-definition-api-stage). Cada estágio é um snapshot da API, sendo disponibilizado para ser chamado pelos aplicativos do cliente.
**Importante**
Toda vez que atualizar uma API, você deverá reimplantá-la. Alterações em qualquer item que não sejam as configurações do estágio exigem uma nova implantação, incluindo modificações nos seguintes recursos:
Rotas
Integrações
Authorizers
Por padrão, você está limitado a dez estágios para cada API. Recomendamos reutilizar estágios para as implantações.
Para chamar uma API WebSocket implantada, o cliente envia uma mensagem à URL da API. A URL é determinada pelo nome do host e pelo nome do estágio da API.
**nota**
O API Gateway oferecerá suporte a cargas de até 128 KB com quadros de máximo 32 KB. Se uma mensagem exceder 32 KB, deve ser dividida em vários quadros, cada qual contendo 32 KB ou menos.
Com o nome de domínio padrão da API, a URL base de uma (por exemplo) API WebSocket em determinado estágio (`{stageName}`) tem o seguinte formato:
```
wss://{api-id}.execute-api.{region}.amazonaws.com/{stageName}
```
Para facilitar o uso da URL da API WebSocket, você pode criar um nome de domínio personalizado (por exemplo, `api.example.com`) para substituir o nome de domínio padrão da API. O processo de configuração é o mesmo utilizado para APIs REST. Para obter mais informações, consulte [Nome de domínio personalizado para APIs REST públicas no API Gateway](how-to-custom-domains.md).
Os estágios permitem um controle de versão robusto para sua API. Por exemplo, você pode implantar uma API em um estágio `test` e um `prod`, e usar o estágio `test` como uma compilação de teste e o estágio `prod` como uma compilação estável. Depois que as atualizações passarem no teste, você poderá promover o estágio `test` para o estágio `prod`. Essa promoção pode ser feita por meio da reimplantação da API ao estágio `prod`. Para obter mais detalhes sobre estágios, consulte [Configurar um estágio para uma API REST no API Gateway](set-up-stages.md).
**Topics**
+ [Criar uma implantação de API do WebSocket usando a AWS CLI](#apigateway-create-websocket-deployment-using-awscli)
+ [Criar uma implantação de API WebSocket usando o console do API Gateway](#apigateway-create-websocket-deployment-using-console)
## Criar uma implantação de API do WebSocket usando a AWS CLI
O seguinte comando [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-deployment.html) cria uma implantação:
```
aws apigatewayv2 --region us-east-1 create-deployment --api-id aabbccddee
```
A saída será exibida da seguinte forma:
```
{
"DeploymentId": "fedcba",
"DeploymentStatus": "DEPLOYED",
"CreatedDate": "2018-11-15T06:49:09Z"
}
```
A API implantada não poderá ser chamada até que a implantação seja associada a um estágio. Você pode criar um novo estágio ou reutilizar um estágio que criou anteriormente.
O comando [create-stage](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-stage.html) indicado abaixo cria um estágio e o associa à implantação:
```
aws apigatewayv2 --region us-east-1 create-stage --api-id aabbccddee --deployment-id fedcba --stage-name test
```
A saída será exibida como a seguir:
```
{
"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": {}
}
```
É possível reutilizar um estágio existente atualizando a propriedade `deploymentId` do estágio com o ID da implantação recém-criado (*deployment-id*). O comando [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-stage.html) indicado abaixo atualiza o ID de implantação do estágio:
```
aws apigatewayv2 update-stage --region region \
--api-id api-id \
--stage-name stage-name \
--deployment-id deployment-id
```
## Criar uma implantação de API WebSocket usando o console do API Gateway
Para usar o console do API Gateway a fim de criar uma implantação para uma API WebSocket:
1. Inicie uma sessão no console do API Gateway e escolha a API.
1. Escolha **Implantar API**.
1. Escolha o estágio desejado na lista suspensa ou insira o nome de um novo estágio.
# Política de segurança para APIs de WebSocket no API Gateway
O API Gateway impõe uma política de segurança de `TLS_1_2` para todos os endpoints da API de WebSocket.
Uma *política de segurança* é uma combinação predefinida da versão mínima do TLS e dos pacotes de criptografia oferecida pelo Amazon API Gateway. O protocolo TLS trata problemas de segurança de rede, como violação e interceptação entre um cliente e o servidor. Quando seus clientes estabelecem um handshake do TLS para a API por meio do domínio personalizado, a política de segurança aplica as opções do pacote de criptografia e da versão do TLS que seus clientes podem optar por usar. Essa política de segurança é compatível com tráfego TLS 1.2 e TLS 1.3 e rejeita tráfego TLS 1.0.
## Protocolos e cifras TLS compatíveis para APIs de WebSocket
A tabela a seguir descreve os protocolos TLS compatíveis com as APIs de WebSocket.
| **Protocolos TLS** | **Política de segurança TLS\$11\$12** |
| --- | --- |
| TLSv1.3 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| TLSv1.2 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
A tabela a seguir descreve as criptografias TLS disponíveis para a política de segurança TLS 1\$12 para APIs de WebSocket.
| **Cifras TLS** | **Política de segurança TLS\$11\$12** |
| --- | --- |
| TLS\$1AES\$1128\$1GCM\$1SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| TLS\$1AES\$1256\$1GCM\$1SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| TLS\$1CHACHA20\$1POLY1305\$1SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| ECDHE-ECDSA-AES128-GCM-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| ECDHE-RSA-AES128-GCM-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| ECDHE-ECDSA-AES128-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| ECDHE-RSA-AES128-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| ECDHE-ECDSA-AES256-GCM-SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| ECDHE-RSA-AES256-GCM-SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| ECDHE-ECDSA-AES256-SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| ECDHE-RSA-AES256-SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| AES128-GCM-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| AES128-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| AES256-GCM-SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
| AES256-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/apigateway/latest/developerguide/images/success_icon.svg) Sim |
## Nomes das criptografias OpenSSL e RFC
OpenSSL e IETF RFC 5246 usam nomes diferentes para as mesmas cifras. Para ver uma lista dos nomes das cifras, consulte [Nomes das criptografias OpenSSL e RFC](apigateway-security-policies-list.md#apigateway-secure-connections-openssl-rfc-cipher-names).
## Informações sobre APIs HTTP e APIs REST
Para saber mais sobre APIs REST e APIs HTTP, consulte [Escolher uma política de segurança para o domínio personalizado no API Gateway](apigateway-custom-domain-tls-version.md) e [Política de segurança para APIs HTTP no API Gateway](http-api-ciphers.md).
# Nomes de domínio personalizados para APIs de WebSocket no API Gateway
Os *nomes de domínio personalizados* são URLs mais simples e intuitivos que você pode fornecer aos usuários da API.
Após a implantação da sua API, você e seus clientes podem invocar essa API usando a URL de base padrão com o seguinte formato:
```
https://api-id.execute-api.region.amazonaws.com/stage
```
em que *api-id* é gerado pelo API Gateway, *region* é a região da AWS e *stage* é especificado por você ao implantar a API.
A parte do nome de host do URL, `api-id.execute-api.region.amazonaws.com`, refere-se a um endpoint de API. O endpoint de API padrão é gerado aleatoriamente, difícil de lembrar e não é simples de usar.
Com nomes de domínio personalizados, você pode configurar o nome de host da API e escolher um caminho base (por exemplo, `myservice`) para mapear o URL alternativo para sua API. Por exemplo, um URL de base de API mais amigável pode se tornar:
```
https://api.example.com/myservice
```
## Considerações
As considerações a seguir podem afetar o uso de um nome de domínio personalizado.
+ Se mapear um nome de domínio personalizado para uma API de WebSocket, você não poderá mapeá-lo para uma API REST ou uma API HTTP.
+ Somente nomes de domínio regionais personalizados são compatíveis.
+ Para a versão mínima de TLS, somente o TLS 1.2 é compatível.
+ É necessário criar ou atualizar o registro de recursos do provedor DNS para ser mapeado ao endpoint da API. Sem esse mapeamento, as solicitações de API que forem direcionadas para o nome de domínio personalizado não conseguirão acessar o API Gateway.
+ É possível comportar um número quase infinito de nomes de domínio sem exceder a cota padrão usando um certificado curinga. Para obter mais informações, consulte [Nomes de domínio personalizados curinga](http-api-custom-domain-names.md#http-wildcard-custom-domain-names).
## Pré-requisitos
Veja a seguir os pré-requisitos de um nome de domínio personalizado.
### Registrar um nome de domínio
É necessário ter um nome de domínio da Internet registrado para configurar nomes de domínio personalizados para as APIs. É possível registrar o domínio da internet usando o [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) ou um registrador de domínios de terceiros da sua escolha. O nome de domínio personalizado pode ser o nome de um subdomínio ou do domínio raiz (também conhecido como “ápex da zona”) de um domínio da internet registrado.
O nome de domínio deve seguir a especificação [RFC 1035](https://tools.ietf.org/html/rfc1035#section-2.3.4) e pode ter no máximo 63 octetos por etiqueta e 255 octetos no total.
### Certificados para nomes de domínio personalizados
Antes de configurar um nome de domínio personalizado para uma API, você deve ter um certificado SSL/TLS pronto no ACM. Se o ACM não estiver disponível na região da AWS onde você está criando o nome de domínio personalizado, será necessário importar um certificado para o API Gateway nessa região.
Para importar um certificado SSL/TLS, você deve fornecer o corpo do certificado SSL/TLS formatado em PEM, sua chave privada e a cadeia de certificado para o nome de domínio personalizado.
Cada certificado armazenado no ACM é identificado por seu ARN. Com certificados emitidos pelo ACM, não é necessário se preocupar em expor detalhes de certificados confidenciais, como a chave privada. Para usar um certificado gerenciado pela AWS para um nome de domínio, basta fazer referência ao seu ARN.
Se o seu aplicativo usa a fixação de certificados, às vezes chamada de fixação SSL, para fixar um certificado do ACM, talvez o aplicativo não consiga se conectar ao seu domínio após a AWS renovar o certificado. Para ter mais informações, consulte [Problemas de fixação do certificado](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-pinning.html) no *Guia do usuário do AWS Certificate Manager*.
## Nomes de domínio personalizados curinga
Com nomes de domínio personalizados curinga, você pode suportar um número quase infinito de nomes de domínio sem exceder a [cota padrão](limits.md). Por exemplo, você pode dar a cada um de seus clientes seu próprio nome de domínio `customername.api.example.com`.
Para criar um nome de domínio personalizado curinga, especifique um curinga (`*`) como o primeiro subdomínio de um domínio personalizado que representa todos os subdomínios possíveis de um domínio raiz.
Por exemplo, o nome de domínio personalizado curinga `*.example.com` resulta em subdomínios, como `a.example.com`, `b.example.com` e `c.example.com`, que são todos roteados para o mesmo domínio.
Os nomes de domínio personalizados curinga oferecem suporte a configurações distintas dos nomes de domínio personalizados padrão do API Gateway. Por exemplo, em uma única conta da AWS, é possível configurar `*.example.com` e `a.example.com` para se comportarem de forma diferente.
Você pode usar as variáveis de contexto `$context.domainName` e `$context.domainPrefix` para determinar o nome de domínio que um cliente usou para chamar sua API. Para saber mais sobre variáveis de contexto, consulte [Variáveis para transformações de dados para o API Gateway](api-gateway-mapping-template-reference.md).
Para criar um nome de domínio personalizado curinga, é necessário fornecer um certificado emitido pelo ACM que foi validado usando o DNS ou o método de validação por e-mail.
**nota**
Não é possível criar um nome de domínio personalizado curinga se uma conta da AWS diferente tiver criado um nome de domínio personalizado que esteja em conflito com o nome de domínio personalizado curinga. Por exemplo, se a conta A tiver criado `a.example.com`, a conta B não poderá criar o nome de domínio personalizado curinga `*.example.com`.
Se a conta A e a conta B compartilham um proprietário, entre em contato com a [Central de Suporte da AWS](https://console.aws.amazon.com/support/home#/) para solicitar uma exceção.
## Próximas etapas para nomes de domínio personalizados
Para configurar um nome de domínio personalizado para uma API HTTP, use a documentação da seção API REST do Guia do desenvolvedor do API Gateway.
Primeiro, especifique o certificado para o nome de domínio personalizado. Para obter mais informações, consulte [Preparar certificados no AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md). Depois, crie um nome de domínio regional personalizado. Para obter mais informações, consulte [Configurar um nome de domínio regional personalizado no API Gateway](apigateway-regional-api-custom-domain-create.md).
# Mapear estágios de API para um nome de domínio personalizado para APIs de WebSocket
Você usa mapeamentos de API para conectar estágios de API a um nome de domínio personalizado. Depois de criar um nome de domínio e configurar registros DNS, você usa mapeamentos de API para enviar tráfego para as suas APIs utilizando o seu nome de domínio personalizado.
Um mapeamento de API especifica uma API, um estágio e, opcionalmente, um caminho a usar para o mapeamento. Por exemplo, você pode mapear o estágio `production` de uma API para `wss://api.example.com/orders`.
Antes de criar um mapeamento de API, você deve ter uma API, um estágio e um nome de domínio personalizado. Para saber mais sobre como criar um nome de domínio personalizado, consulte [Configurar um nome de domínio regional personalizado no API Gateway](apigateway-regional-api-custom-domain-create.md).
## Restrições
+ Em um mapeamento de API, o nome de domínio personalizado e as APIs mapeadas devem estar na mesma conta da AWS.
+ Os mapeamentos de API devem conter apenas letras, números e os caracteres a seguir: `$-_.+!*'()`.
+ O comprimento máximo para o caminho em um mapeamento de API é de 300 caracteres.
+ Você não pode mapear APIs WebSocket para o mesmo nome de domínio personalizado que uma API HTTP ou API REST.
+ Se você criar mapeamentos de API com vários níveis, o API Gateway mudará todos os nomes de cabeçalho para minúsculas.
## Crie um mapeamento de API
Para criar um mapeamento de API, você deve primeiro criar um nome de domínio personalizado, uma API e um estágio. Para obter informações sobre como criar um nome de domínio personalizado, consulte [Configurar um nome de domínio regional personalizado no API Gateway](apigateway-regional-api-custom-domain-create.md).
------
#### [ Console de gerenciamento da AWS ]
**Para criar um mapeamento de API**
1. Inicie uma sessão no console do API Gateway em [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Escolha **Custom domain names** (Nomes de domínios personalizados).
1. Selecione um nome de domínio personalizado que você já criou.
1. Escolha **API mappings** (Mapeamentos de API).
1. Escolha **Configure API mappings (Configurar mapeamentos de API)**.
1. Escolha **Add new mapping (Adicionar novo mapeamento)**.
1. Insira uma **API**, um **Estágio** e, opcionalmente, um **Caminho**.
1. Escolha **Salvar**.
------
#### [ AWS CLI ]
O comando [create-api-mapping](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api-mapping.html) a seguir cria um mapeamento de API. Neste exemplo, o API Gateway envia solicitações para `api.example.com/v1` para a API e o estágio especificados.
```
aws apigatewayv2 create-api-mapping \
--domain-name api.example.com \
--api-mapping-key v1 \
--api-id a1b2c3d4 \
--stage test
```
------
#### [ CloudFormation ]
O exemplo de CloudFormation a seguir cria um mapeamento de API.
```
MyApiMapping:
Type: 'AWS::ApiGatewayV2::ApiMapping'
Properties:
DomainName: api.example.com
ApiMappingKey: 'v1'
ApiId: !Ref MyApi
Stage: !Ref MyStage
```
------
# Tipos de endereço IP para nomes de domínio personalizados para APIs de WebSocket
Ao criar um nome de domínio personalizado, você especifica o tipo de endereços IP que podem invocar seu domínio. É possível escolher IPv4 para resolver endereços IPv4 e invocar seu domínio ou escolher pilha dupla para permitir que endereços IPv4 e IPv6 invoquem seu domínio. Recomendamos que você defina o tipo de endereço IP como pilha dupla para aliviar o esgotamento do espaço IP ou para seu procedimento de segurança. Para ter mais informações sobre os benefícios de um tipo de endereço IP de pilha dupla, consulte [IPv6 na AWS](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/internet-protocol-version-6.html).
## Considerações sobre tipos de endereço IP
As considerações a seguir podem afetar o uso de tipos de endereço IP.
+ O tipo de endereço IP padrão para nomes de domínio personalizados do API Gateway é IPv4.
+ Seu nome de domínio personalizado não precisa ter o mesmo tipo de endereço IP para todas as APIs associadas a ele. Se você desabilitar seu endpoint de API padrão, isso poderá afetar como os chamadores podem invocar sua API.
## Alterar o tipo de endereço IP do nome de domínio personalizado
É possível alterar o tipo de endereço IP atualizando a configuração do endpoint do nome de domínio. É possível atualizar a configuração do endpoint usando o Console de gerenciamento da AWS, a AWS CLI, o CloudFormation ou um SDK da AWS.
------
#### [ Console de gerenciamento da AWS ]
**Como alterar o tipo de endereço IP de um nome de domínio personalizado**
1. Faça login no console do API Gateway em [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Escolha um nome de domínio personalizado público.
1. Escolha **Configurações de endpoint**.
1. Em Tipo de endereço IP, escolha **IPv4** ou **Pilha dupla**.
1. Escolha **Salvar**.
------
#### [ AWS CLI ]
O comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html) a seguir atualiza uma API para ter um tipo de endereço IP de pilha dupla:
```
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
```
A saída será exibida da seguinte forma:
```
{
"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": {}
}
```
------
# Desabilitar o endpoint padrão para APIs de WebSocket
Por padrão, os clientes podem invocar sua API usando o endpoint `execute-api` gerado pelo API Gateway para sua API. Para garantir que os clientes possam acessar sua API somente usando um nome de domínio personalizado, desabilite o endpoint `execute-api` padrão. Quando o endpoint padrão é desabilitado, ele afeta todos os estágios de uma API.
O procedimento a seguir mostra como desabilitar o endpoint padrão de uma API de WebSocket.
------
#### [ Console de gerenciamento da AWS ]
1. Faça login no console do API Gateway em [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Escolha uma API de WebSocket.
1. Escolha **Configurações da API**.
1. Em **Detalhes da API**, escolha **Editar**.
1. Em **Endpoint padrão**, selecione **Inativo**.
1. Escolha **Salvar alterações**.
1. No painel de navegação principal, selecione **Rotas**.
1. Selecione **Implantar** e reimplante a API ou crie uma etapa para que a alteração entre em vigor.
------
#### [ AWS CLI ]
O comando [update-api](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-api.html) indicado abaixo desabilita o endpoint padrão para uma API de WebSocket.
```
aws apigatewayv2 update-api \
--api-id abcdef123 \
--disable-execute-api-endpoint
```
Depois de desabilitar o endpoint padrão, é necessário implantar sua API para que a alteração entre em vigor.
O comando da AWS CLI a seguir cria uma implantação.
```
aws apigatewayv2 create-deployment \
--api-id abcdef123 \
--stage-name dev
```
------