# Visão geral das APIs de WebSocket no API Gateway
<a name="apigateway-websocket-api-overview"></a>

No API Gateway, é possível criar uma API WebSocket como um frontend com estado para um serviço da AWS (como Lambda ou DynamoDB) ou para um endpoint HTTP. A API WebSocket invoca o backend com base no conteúdo de mensagens que recebe a partir de aplicativos do cliente.

Ao contrário de uma API REST, que recebe e responde a solicitações, uma API WebSocket oferece suporte a comunicações bidirecionais entre aplicativos do cliente e backend. O backend pode enviar mensagens de retorno para clientes conectados.

Na sua API WebSocket, mensagens JSON de entrada são direcionadas para integrações de backend com base nas rotas que você configurar. (Mensagens que não apresentam o formato JSON são direcionadas para a rota `$default` que você configurar).

Uma *rota* inclui uma *chave de roteamento*, que é o valor esperado quando uma *expressão de seleção de rotas* é avaliada. O `routeSelectionExpression` é um atributo definido em nível de API. Ele especifica uma propriedade JSON que deve estar presente na carga da mensagem. Para obter mais informações sobre expressões de seleção de rota, consulte [Expressões de seleção de rota](websocket-api-develop-routes.md#apigateway-websocket-api-route-selection-expressions).

Por exemplo, se as suas mensagens JSON contêm uma propriedade `action` e você deseja realizar ações diferentes de acordo com essa propriedade, sua expressão de seleção de rotas pode ser `${request.body.action}`. A tabela de roteamento deve especificar qual ação executar ao corresponder o valor da propriedade `action` com os valores de chave de rotas personalizada que você definiu na tabela.

## Usar rotas para uma API de WebSocket
<a name="apigateway-websocket-api-overview-routes"></a>

Há três rotas predefinidas que podem ser usadas: `$connect`, `$disconnect` e `$default`. Além disso, você pode criar rotas personalizadas.
+ O API Gateway chama a rota `$connect` quando uma conexão persistente entre o cliente e uma API WebSocket está sendo iniciada.
+ O API Gateway chama a rota `$disconnect` quando o cliente ou o servidor é desconectado da API.
+ O API Gateway chama uma rota personalizada após a avaliação da expressão de seleção de rotas personalizada em relação à mensagem caso uma rota correspondente seja encontrada; a correspondência determina qual integração é invocada.
+ O API Gateway chamará a rota `$default` se a expressão de seleção de rotas não puder ser avaliada em relação à mensagem ou se nenhuma rota correspondente for encontrada.

Para obter mais informações sobre as rotas `$connect` e `$disconnect`, consulte [Gerenciar usuários conectados e aplicações clientes: rotas `$connect` e `$disconnect`](apigateway-websocket-api-route-keys-connect-disconnect.md).

Para obter mais informações sobre a rota `$default` e rotas personalizadas, consulte [Invocar sua integração de backend com o `$default` Route e rotas personalizadas no API Gateway](apigateway-websocket-api-routes-integrations.md).

## Enviar dados a aplicações de cliente conectadas
<a name="apigateway-websocket-api-overview-send-data"></a>

Os serviços de backend podem enviar dados para aplicativos conectados do cliente. É possível enviar dados fazendo o seguinte:
+ Use uma integração para enviar uma resposta, que é exibida ao cliente por uma resposta de rota que você tiver definido.
+ Você pode usar a API `@connections` para enviar uma solicitação POST: Para obter mais informações, consulte [Usar os comandos `@connections` em seu serviço de backend](apigateway-how-to-call-websocket-api-connections.md).

## Códigos de status API de WebSocket
<a name="apigateway-websocket-status-codes"></a>

As APIs de WebSocket do Gateway da API usam os seguintes códigos de status para comunicação do servidor com o cliente, conforme descrito no [Registro de número de código de fechamento WebSocket](https://www.iana.org/assignments/websocket/websocket.xhtml#close-code-number):

1001  
O API do Gateway retorna esse código de status quando o cliente fica inativo por 10 minutos ou atinge a vida útil máxima de conexão de 2 horas.

1003  
O Gateway da API retorna esse código de status quando um endpoint recebe um tipo de mídia binária. Tipos de mídia binária não têm suporte para APIs de WebSocket.

1005  
O Gateway da API retorna esse código de status se o cliente enviar um quadro de fechamento sem um código de encerramento.

1006  
O Gateway da API retorna esse código de status se houver um fechamento inesperado da conexão, como a conexão TCP fechada sem um quadro de fechamento do WebSocket.

1008  
O Gateway da API retorna esse código de status quando um endpoint recebe muitas solicitações de um cliente específico.

1009  
O Gateway da API retorna esse código de status quando um endpoint recebe uma mensagem grande demais para ser processada.

1011  
O Gateway da API retorna esse código de status quando há um erro interno do servidor. 

1012  
O Gateway da API retorna esse código de status se o serviço for reiniciado.

# Gerenciar usuários conectados e aplicações clientes: rotas `$connect` e `$disconnect`
<a name="apigateway-websocket-api-route-keys-connect-disconnect"></a>

A seção a seguir descreve como usar as rotas `$connect` e `$disconnect` para sua API de WebSocket.

**Topics**
+ [A rota `$connect`](#apigateway-websocket-api-routes-about-connect)
+ [Transmitir informações de conexão da rota `$connect`](#apigateway-websocket-api-passing-connectionId-on-connect)
+ [A rota `$disconnect`](#apigateway-websocket-api-routes-about-disconnect)

## A rota `$connect`
<a name="apigateway-websocket-api-routes-about-connect"></a>

Os aplicativos do cliente se conectam à sua API WebSocket ao enviar uma solicitação de atualização do WebSocket. Se a solicitação for bem-sucedida, a rota `$connect` é executada enquanto a conexão estiver sendo criada.

Como a conexão do WebSocket é uma conexão stateful, você pode configurar a autorização somente na rota `$connect`. `AuthN`/`AuthZ` será realizada somente pelo tempo de conexão.

Enquanto a execução de integração associada à rota `$connect` é concluída, a solicitação de atualização está pendente e a conexão real não será estabelecida. Se a solicitação `$connect` falhar (por exemplo, devido a uma falha `AuthN`/`AuthZ` ou falha de integração), a conexão não será estabelecida.

**nota**  
Se a autorização falhar em `$connect`, a conexão não será estabelecida, e o cliente receberá uma resposta `401` ou `403`.

A configuração de uma integração para `$connect` é opcional. Você deve considerar configurar uma integração `$connect` se:
+ Deseja permitir que os clientes especifiquem subprotocolos usando o campo `Sec-WebSocket-Protocol`. Para ver um código demonstrativo, consulte [Configurar uma rota `$connect` que requer um subprotocolo de WebSocket](websocket-connect-route-subprotocol.md).
+ Deseja receber notificação quando os clientes se conectarem.
+ Deseja limitar as conexões ou controlar quem se conecta.
+ Deseja que o backend envie mensagens de volta aos clientes usando uma URL de retorno de chamada.
+ Deseja armazenar cada ID de conexão e outras informações em um banco de dados (por exemplo, Amazon DynamoDB).

## Transmitir informações de conexão da rota `$connect`
<a name="apigateway-websocket-api-passing-connectionId-on-connect"></a>

 É possível usar integrações de proxy e não proxy para transmitir informações da rota `$connect` para um banco de dados ou outro AWS service (Serviço da AWS). 

### Como transmitir informações de conexão usando uma integração de proxy
<a name="websocket-connect-proxy-integration"></a>

É possível acessar as informações de conexão por uma integração de proxy do Lambda no evento. Use outro AWS service (Serviço da AWS) ou função do AWS Lambda para publicar na conexão. 

A função do Lambda a seguir mostra como usar o objeto `requestContext` para registrar o ID da conexão, o nome do domínio, o nome do estágio e as strings de consulta. 

------
#### [ Node.js ]

```
 export const handler = async(event, context) => {
    const connectId = event["requestContext"]["connectionId"]
    const domainName = event["requestContext"]["domainName"]
    const stageName = event["requestContext"]["stage"]
    const qs = event['queryStringParameters']
    console.log('Connection ID: ', connectId, 'Domain Name: ', domainName, 'Stage Name: ', stageName, 'Query Strings: ', qs )
    return {"statusCode" : 200}
};
```

------
#### [ Python ]

```
import json
import logging
logger = logging.getLogger()
logger.setLevel("INFO")


def lambda_handler(event, context):
    connectId = event["requestContext"]["connectionId"]
    domainName = event["requestContext"]["domainName"]
    stageName = event["requestContext"]["stage"]
    qs = event['queryStringParameters']
    connectionInfo = {
        'Connection ID': connectId,
        'Domain Name': domainName,
        'Stage Name': stageName,
        'Query Strings': qs}
    logging.info(connectionInfo)
    return {"statusCode": 200}
```

------

### Como transmitir informações de conexão usando uma integração que não seja de proxy
<a name="websocket-connect-non-proxy-integration"></a>
+ É possível acessar as informações de conexão com uma integração não proxy. Configure a solicitação de integração e forneça um modelo de solicitação da API de WebSocket. O modelo de mapeamento [Velocity Template Language (VTL)](https://velocity.apache.org/engine/devel/vtl-reference.html) a seguir fornece uma solicitação de integração. Essa solicitação envia os seguintes detalhes para uma integração sem proxy: 
  + ID da conexão
  + Nome de domínio
  + Nome da etapa
  + Path
  + Cabeçalhos
  + Strings de consulta

  Essa solicitação envia o ID da conexão, o nome do domínio, o nome do estágio, os caminhos, os cabeçalhos e as strings de consulta para uma integração sem proxy.

  ```
  {
      "connectionId": "$context.connectionId",
      "domain": "$context.domainName",
      "stage": "$context.stage",
      "params": "$input.params()"
  }
  ```

  Para obter mais informações sobre a configuração de transformações de dados, consulte [Transformações de dados para APIs de WebSocket no API Gateway](websocket-api-data-transformations.md).

  Para concluir a solicitação de integração, defina `StatusCode: 200` para a resposta de integração. Para saber mais sobre como configurar uma resposta de integração, consulte [Configurar uma resposta de integração usando o console do API Gateway](apigateway-websocket-api-integration-responses.md#apigateway-websocket-api-integration-response-using-console).

## A rota `$disconnect`
<a name="apigateway-websocket-api-routes-about-disconnect"></a>

A rota `$disconnect` é executada depois de a conexão ser encerrada.

A conexão pode ser encerrada pelo servidor ou pelo cliente. Como a conexão já está fechada quando é executado, `$disconnect` é um evento de melhor esforço. O API Gateway tentará o seu melhor para entregar o evento `$disconnect` à sua integração, mas não pode garantir a entrega.

O backend pode iniciar a desconexão ao utilizar a API `@connections`. Para obter mais informações, consulte [Usar os comandos `@connections` em seu serviço de backend](apigateway-how-to-call-websocket-api-connections.md).

# Invocar sua integração de backend com o `$default` Route e rotas personalizadas no API Gateway
<a name="apigateway-websocket-api-routes-integrations"></a>

A seção a seguir descreve como invocar sua integração de backend usando a rota `$default` ou uma rota personalizada para uma API de WebSocket.

**Topics**
+ [Usar rotas para processar mensagens](#apigateway-websocket-api-overview-routes)
+ [A rota `$default`](#apigateway-websocket-api-routes-about-default)
+ [Rotas personalizadas](#apigateway-websocket-api-routes-about-custom)
+ [Usar integrações da API WebSocket do API Gateway para se conectar à sua lógica de negócios](#apigateway-websocket-api-overview-integrations)
+ [Diferenças importantes entre APIs WebSocket e APIs REST](#apigateway-websocket-api-overview-integrations-differences)

## Usar rotas para processar mensagens
<a name="apigateway-websocket-api-overview-routes"></a>

Nas APIs WebSocket do API Gateway, as mensagens podem ser enviadas do cliente para o serviço de backend e vice-versa. Ao contrário do modelo de solicitação/resposta HTTP, no WebSocket é possível que o backend envie mensagens para o cliente sem que o cliente realize qualquer ação.

As mensagens podem estar no formato JSON ou não. No entanto, somente as mensagens JSON podem ser roteadas para integrações específicas com base no conteúdo da mensagem. As mensagens que não estão no formato JSON não são transmitidas ao backend pela rota `$default`.

**nota**  
O API Gateway é compatível com cargas de mensagem de até 128 KB com quadros no tamanho máximo de 32 KB. Se uma mensagem exceder 32 KB, é necessário dividi-la em vários quadros, cada qual contendo 32 KB ou menos. Se uma mensagem (ou quadro) maior for recebida, a conexão será encerrada com o código 1009.  
Atualmente, cargas binárias não são compatíveis. Se um quadro binário for recebido, a conexão será encerrada com o código 1003. No entanto, é possível converter cargas binárias para texto. Consulte [Tipos de mídia binários para APIs de WebSocket no API Gateway](websocket-api-develop-binary-media-types.md).

Com APIs WebSocket no API Gateway, as mensagens JSON podem ser roteadas para executar um serviço de backend determinado com base no conteúdo da mensagem. Quando um cliente envia uma mensagem sobre sua conexão WebSocket, isso resulta em uma *solicitação de rota* para a API WebSocket. A solicitação será vinculada à rota com a chave da rota correspondente no API Gateway. É possível configurar uma solicitação de rota para uma API WebSocket no console do API Gateway, usando a AWS CLI ou um AWS SDK.

**nota**  
Na AWS CLI e nos AWS SDKs, você pode criar rotas antes ou depois de criar integrações. Atualmente, o console não oferece suporte à reutilização de integrações, portanto, você deve criar a rota primeiro e, em seguida, gerar a integração para essa rota.

É possível configurar o API Gateway para realizar a validação em uma solicitação de rota antes de prosseguir com a solicitação de integração. Se ocorrer uma falha na validação, o API Gateway não atenderá à solicitação sem chamar o backend, enviará uma resposta do gateway `"Bad request body"` semelhante à seguinte para o cliente e publicará os resultados da validação no CloudWatch Logs: 

```
{"message" : "Bad request body", "connectionId": "{connectionId}", "messageId": "{messageId}"}
```

Isso reduz as chamadas desnecessárias para o backend e permite que você se concentre em outros requisitos da sua API.

Você também pode definir uma resposta de rota para suas rotas da API, permitindo comunicações bidirecionais. Uma resposta de rota descreve quais dados serão enviados ao cliente após a conclusão da integração de uma rota determinada. Não é necessário definir uma resposta para uma rota se, por exemplo, você deseja que um cliente envie mensagens para o backend sem receber uma resposta (comunicação unidirecional). No entanto, se você não fornecer uma resposta de rota, o API Gateway não enviará nenhuma informação sobre o resultado da sua integração aos clientes.

## A rota `$default`
<a name="apigateway-websocket-api-routes-about-default"></a>

Cada API WebSocket do API Gateway pode ter uma rota `$default`. Esse é um valor de roteamento especial que pode ser usado das seguintes formas:
+ Você pode usá-lo em conjunto com chaves de roteamento definidas, para especificar uma rota de "fallback" (por exemplo, uma integração simulada genérica que retorna determinada mensagem de erro) para mensagens recebidas que não corresponderem a nenhuma das chaves de roteamento definidas.
+ Você pode usá-lo sem qualquer chave de roteamento definida para especificar um modelo de proxy que delega o roteamento a um componente de backend.
+ Você pode usá-lo para especificar uma rota para cargas que não estão no formato JSON.

## Rotas personalizadas
<a name="apigateway-websocket-api-routes-about-custom"></a>

Se deseja invocar uma integração específica com base no conteúdo da mensagem, você pode fazê-lo ao criar uma rota personalizada.

A rota personalizada utiliza uma chave de roteamento e a integração que você especificar. Quando uma mensagem de entrada contém uma propriedade JSON, e essa propriedade é avaliada como um valor que corresponde ao valor da chave de roteamento, o API Gateway invoca a integração. (Para obter mais informações, consulte [Visão geral das APIs de WebSocket no API Gateway](apigateway-websocket-api-overview.md).)

Por exemplo, suponha que você queira criar um aplicativo de salas de bate-papo. Você pode começar com a criação de uma API WebSocket cuja expressão de seleção de rotas é `$request.body.action`. Em seguida, você pode definir duas rotas: `joinroom` e `sendmessage`. Um aplicativo do cliente pode invocar a rota `joinroom` ao enviar uma mensagem como a seguinte:

```
{"action":"joinroom","roomname":"developers"}
```

Também pode invocar a rota `sendmessage` ao enviar uma mensagem como a seguinte:

```
{"action":"sendmessage","message":"Hello everyone"}
```

## Usar integrações da API WebSocket do API Gateway para se conectar à sua lógica de negócios
<a name="apigateway-websocket-api-overview-integrations"></a>

Após a configuração de uma rota para uma API WebSocket do API Gateway, é necessário especificar a integração a ser utilizada. Assim como ocorre com uma rota, que pode apresentar uma solicitação de rota e uma resposta de rota, uma integração pode apresentar uma *solicitação de integração* e uma *resposta de integração*. Uma *solicitação de integração* contém as informações esperadas pelo backend para processar a solicitação recebida de seu cliente. Uma *resposta de integração* contém os dados que o backend retorna para o API Gateway e que podem ser usados para elaborar uma mensagem a ser enviada ao cliente (se uma resposta de rota for definida).

Para obter mais informações sobre a configuração de integrações, consulte [Integrações para APIs de WebSocket no API Gateway](apigateway-websocket-api-integrations.md).

## Diferenças importantes entre APIs WebSocket e APIs REST
<a name="apigateway-websocket-api-overview-integrations-differences"></a>

Integrações para APIs do WebSocket são semelhantes às integrações para APIs REST, exceto com relação às seguintes diferenças:
+ Atualmente, no console do API Gateway, é necessário criar uma rota primeiro e, depois, criar uma integração como o destino da rota. No entanto, na API e CLI, você pode criar rotas e integrações de maneira independente, em qualquer ordem.
+ Você pode usar uma única integração para várias rotas. Por exemplo, se você tiver um conjunto de ações que tenham uma relação estreita entre si, é recomendável que todas essas rotas sejam direcionadas a uma única função do Lambda. Em vez de definir os detalhes da integração várias vezes, você pode especificá-los uma vez e atribuí-los a cada uma das rotas relacionadas.
**nota**  
Atualmente, o console não oferece suporte à reutilização de integrações, portanto, você deve criar a rota primeiro e, em seguida, gerar a integração para essa rota.  
Na AWS CLI e nos AWS SDKs, você pode reutilizar uma integração definindo o destino da rota como um valor de `"integrations/{integration-id}"`, em que `{integration-id}"` é o ID exclusivo da integração a ser associada à rota.
+ O API Gateway fornece várias [expressões de seleção](apigateway-websocket-api-selection-expressions.md) que podem ser usadas em suas rotas e integrações. Você não precisa depender do tipo de conteúdo para selecionar um modelo de entrada ou mapeamento de saída. Assim como ocorre com expressões de seleção de rotas, você pode definir uma expressão de seleção a ser avaliada pelo API Gateway para escolher o item correto. Todas elas serão recuadas para o modelo `$default` se um modelo correspondente não for encontrado.
  + Nas solicitações de integração, a expressão de seleção do modelo é compatível com `$request.body.<json_path_expression>` e valores estáticos.
  + Nas respostas de integração, a expressão de seleção do modelo é compatível com `$request.body.<json_path_expression>`, `$integration.response.statuscode`, `$integration.response.header.<headerName>` e valores estáticos.

No protocolo HTTP, em que solicitações e respostas são enviadas de forma síncrona, a comunicação é essencialmente unidirecional. No protocolo WebSocket, a comunicação é bidirecional. As respostas são assíncronas e não são necessariamente recebidas pelo cliente na mesma ordem em que as mensagens do cliente foram enviadas. Além disso, o backend pode enviar mensagens ao cliente.

**nota**  
Para uma rota que é configurada para utilizar a integração `AWS_PROXY` ou `LAMBDA_PROXY`, a comunicação é unidirecional, e o API Gateway não transmitirá automaticamente a resposta de backend para a resposta de rota. Por exemplo, no caso da integração `LAMBDA_PROXY`, o corpo retornado pela função do Lambda não será retornado ao cliente. Se deseja que o cliente receba respostas de integração, você deve definir uma resposta de rota para possibilitar a comunicação bidirecional.

# Expressões de seleção do WebSocket
<a name="apigateway-websocket-api-selection-expressions"></a>

O API Gateway usa expressões de seleção como uma maneira de avaliar o contexto de solicitação e resposta e produzir uma chave. A chave é utilizar para selecionar a partir de um conjunto de valores possíveis, normalmente fornecidos por você, que é o desenvolvedor da API. O conjunto exato de variáveis compatíveis varia de acordo com a expressão específica. Cada expressão é discutir a seguir com mais detalhes.

Para todas as expressões, o idioma segue o mesmo conjunto de regras:
+ Uma variável é prefixada com `"$"`.
+ As chaves podem ser usadas para definir explicitamente os limites da variável, por exempl., `"${request.body.version}-beta"`.
+ Várias variáveis são compatíveis, mas a avaliação ocorre somente uma vez (sem avaliação recursiva).
+ Um cifrão (`$`) pode ser recuado com `"\"`. Isso é mais útil ao definir uma expressão que mapeia para a chave reservada `$default`, por exemplo, `"\$default"`.
+ Em alguns casos, um formato padrão é obrigatório. Nesse caso, a expressão deve ser encapsulada com barras (`"/"`), por exemplo, `"/2\d\d/"` para corresponder aos códigos de status `2XX`.

**Topics**
+ [Expressões de seleção de resposta de rotas](#apigateway-websocket-api-route-response-selection-expressions)
+ [Expressões de seleção de chave da API](#apigateway-websocket-api-apikey-selection-expressions)
+ [Expressões de seleção de mapeamento da API](#apigateway-websocket-api-mapping-selection-expressions)
+ [Resumo da expressão de seleção do WebSocket](#apigateway-websocket-api-selection-expression-table)

## Expressões de seleção de resposta de rotas
<a name="apigateway-websocket-api-route-response-selection-expressions"></a>

Uma [resposta de rota](apigateway-websocket-api-route-response.md) é utilizada para modelar uma resposta do backend para o cliente. Para APIs WebSocket, uma resposta de rota é opcional. Quando definida, emite sinais para o API Gateway de que deve retornar uma resposta a um cliente após o recebimento de uma mensagem WebSocket.

A avaliação da *expressão de seleção de resposta de rotas* produz uma chave de resposta de rotas. Por fim, essa chave será usada para escolher um dos [https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-routes-routeid-routeresponses.html](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-routes-routeid-routeresponses.html) associados à API. No entanto, a única chave atualmente compatível é `$default`.

## Expressões de seleção de chave da API
<a name="apigateway-websocket-api-apikey-selection-expressions"></a>

Esta expressão é avaliada quando o serviço determina que uma dada solicitação deve continuar somente se o cliente fornecer uma [chave de API](api-gateway-basic-concept.md#apigateway-definition-api-key) válida.

Atualmente, os únicos dois valores compatíveis são `$request.header.x-api-key` e `$context.authorizer.usageIdentifierKey`.

## Expressões de seleção de mapeamento da API
<a name="apigateway-websocket-api-mapping-selection-expressions"></a>

Esta expressão é avaliada para determinar qual estágio de API é selecionado quando uma solicitação é feita por meio de um domínio personalizado.

Atualmente, o único valor compatível é `$request.basepath`.

## Resumo da expressão de seleção do WebSocket
<a name="apigateway-websocket-api-selection-expression-table"></a>

A tabela a seguir resume os casos de uso para expressões de seleção em APIs WebSocket:


| Expressão de seleção | Avalia chave para | Observações | Exemplo de caso de uso | 
| --- | --- | --- | --- | 
| Api.RouteSelectionExpression | Route.RouteKey | \$1default é compatível como uma rota genérica. | Roteie mensagens WebSocket com base no contexto de uma solicitação do cliente. | 
| Route.ModelSelectionExpression | Chave para Route.RequestModels | Opcional. Se fornecida para integração não proxy, a validação do modelo ocorre. `$default` é compatível como um genérico.  | Execute a validação de solicitação dinamicamente na mesma rota. | 
| Integration.TemplateSelectionExpression | Chave para Integration.RequestTemplates |  Opcional. Pode ser fornecida para integração não proxy visando manipular as cargas de entrada. `${request.body.jsonPath}` e valores estáticos são compatíveis. `$default` é compatível como um genérico.  | Manipular a solicitação do autor da chamada nas propriedades dinâmicas da solicitação. | 
| Integration.IntegrationResponseSelectionExpression | IntegrationResponse.IntegrationResponseKey |  Opcional. Pode ser fornecida para integração não proxy. Funciona como uma correspondência de padrão para mensagens de erro (do Lambda) ou códigos de status (de integrações HTTP). `$default` é necessário para integrações não proxy visando atuar como um genérico para respostas bem-sucedidas.  |  Manipular a resposta do backend. Escolha a ação que deve ocorrer com base na resposta dinâmica do backend (por exemplo, manipular determinados erros de forma distinta).  | 
| IntegrationResponse.TemplateSelectionExpression | Chave para IntegrationResponse.ResponseTemplates | Opcional. Pode ser fornecida para integração não proxy. O padrão \$1 é compatível.  |  Em alguns casos, uma propriedade dinâmica da resposta pode ditar transformações diferentes na mesma rota e integração associada. `${request.body.jsonPath}`, `${integration.response.statuscode}`, `${integration.response.header.headerName}`, `${integration.response.multivalueheader.headerName}`, e valores estáticos são compatíveis. `$default` é compatível como um genérico.  | 
| Route.RouteResponseSelectionExpression | RouteResponse.RouteResponseKey |  Deve ser fornecido para iniciar a comunicação bidirecional para uma rota do WebSocket. Atualmente, este valor é restrito apenas ao `$default`.  |  | 
| RouteResponse.ModelSelectionExpression | Chave para RouteResponse.RequestModels | Atualmente incompatível. |  |