Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Panoramica di WebSocket APIs in API Gateway
In API Gateway puoi creare un' WebSocket API come frontend stateful per un AWS servizio (come Lambda o DynamoDB) o per un endpoint HTTP. L' WebSocket API richiama il backend in base al contenuto dei messaggi che riceve dalle app client.
A differenza di un'API REST, che riceve e risponde alle richieste, un' WebSocket API supporta la comunicazione bidirezionale tra le app client e il backend. Il back-end può inviare messaggi di callback a client connessi.
Nella tua WebSocket API, i messaggi JSON in entrata vengono indirizzati alle integrazioni di backend in base ai percorsi che configuri. (Messaggi non JSON sono indirizzati a una route `$default` configurata dall'utente).
Una *route* include una *chiave di route*, che è il valore previsto dopo che un'*espressione di selezione della route* è stata valutata. `routeSelectionExpression` è un attributo definito a livello di API. Specifica una proprietà JSON che deve essere presente nel payload del messaggio. Per ulteriori informazioni sulle espressioni di selezione della route, consulta [Espressioni di selezione dell'instradamento](websocket-api-develop-routes.md#apigateway-websocket-api-route-selection-expressions).
Ad esempio, se i messaggi JSON contengono una proprietà `action` e desideri eseguire operazioni diverse in base a questa proprietà, l'espressione di selezione della route potrebbe essere `${request.body.action}`. La tabella di routing specifica quale operazione eseguire abbinando il valore della proprietà `action` ai valori delle chiavi route personalizzate definiti nella tabella.
## Usa i percorsi per un'API WebSocket
Esistono tre route predefinite che possono essere utilizzate: `$connect`, `$disconnect` e `$default`. Inoltre, puoi creare route personalizzate.
+ API Gateway chiama il `$connect` percorso quando viene avviata una connessione persistente tra il client e un' WebSocket API.
+ API Gateway chiama la route `$disconnect` quando il client o il server si scollega dall'API.
+ API Gateway chiama una route personalizzata dopo che l'espressione di selezione della route viene valutata rispetto al messaggio, se viene trovata una route corrispondente; la corrispondenza determina quale integrazione viene richiamata.
+ API Gateway chiama la route `$default` se l'espressione di selezione della route non può essere valutata rispetto al messaggio o se non viene trovata una route corrispondente.
Per ulteriori informazioni sulle route `$connect` e `$disconnect`, consulta [Gestione di utenti connessi e app client: instradamenti `$connect` e `$disconnect`](apigateway-websocket-api-route-keys-connect-disconnect.md).
Per ulteriori informazioni sulla route `$default` e le route personalizzate, consulta [Invocazione dell'integrazione backend con l'instradamento `$default` e gli instradamenti personalizzati in Gateway API](apigateway-websocket-api-routes-integrations.md).
## Invio dei dati alle app client connesse
I servizi di back-end possono inviare dati alle app client connesse. È possibile inviare i dati nel modo seguente:
+ Utilizza un'integrazione per inviare una risposta, che viene restituita al client da una risposta di instradamento definita.
+ Puoi utilizzare l'API `@connections` per inviare una richiesta POST. Per ulteriori informazioni, consulta [Utilizzo di comandi `@connections` nel servizio di back-end](apigateway-how-to-call-websocket-api-connections.md).
## WebSocket Codici di stato delle API
API Gateway WebSocket APIs utilizza i seguenti codici di stato per la comunicazione dal server al client, come descritto nel [WebSocket Close Code Number Registry](https://www.iana.org/assignments/websocket/websocket.xhtml#close-code-number):
1001
Gateway API restituisce questo codice di stato quando il client è inattivo per 10 minuti o raggiunge la durata massima della connessione di 2 ore.
1003
Gateway API restituisce questo codice di stato quando un endpoint riceve un tipo di supporto binario. I tipi di file multimediali binari non sono supportati per WebSocket APIs.
1005
Gateway API restituisce questo codice di stato se il client invia un frame chiuso senza codice di chiusura.
1006
API Gateway restituisce questo codice di stato in caso di chiusura imprevista della connessione, ad esempio la connessione TCP chiusa senza un frame WebSocket chiuso.
1008
Gateway API restituisce questo codice di stato quando un endpoint riceve troppe richieste da un determinato client.
1009
Gateway API restituisce questo codice di stato quando un endpoint riceve un messaggio troppo grande per essere elaborato.
1011
Gateway API restituisce questo codice di stato in caso di errore interno del server.
1012
Gateway API restituisce questo codice di stato se il servizio si riavvia.
# Gestione di utenti connessi e app client: instradamenti `$connect` e `$disconnect`
La sezione seguente descrive come utilizzare `$connect` e i `$disconnect` percorsi per la tua WebSocket API.
**Topics**
+ [Instradamento `$connect`](#apigateway-websocket-api-routes-about-connect)
+ [Passaggio delle informazioni di connessione dalla route `$connect`](#apigateway-websocket-api-passing-connectionId-on-connect)
+ [Instradamento `$disconnect`](#apigateway-websocket-api-routes-about-disconnect)
## Instradamento `$connect`
Le app client si connettono alla tua WebSocket API inviando una richiesta di WebSocket aggiornamento. Se la richiesta ha esito positivo, la route `$connect` viene eseguita mentre la connessione viene stabilita.
Poiché la WebSocket connessione è una connessione con stato, puoi configurare l'autorizzazione solo sulla `$connect` route. `AuthN`/`AuthZ`verrà eseguito solo al momento della connessione.
Finché l'esecuzione dell'integrazione associata alla route `$connect` non viene completata, la richiesta di aggiornamento è in sospeso e la connessione effettiva non verrà stabilita. Se la richiesta `$connect` ha esito negativo (ad esempio, a causa di un errore `AuthN`/`AuthZ` o errore di integrazione), la connessione non verrà stabilita.
**Nota**
Se l'autorizzazione ha esito negativo su `$connect`, la connessione non verrà stabilita e il client riceverà una risposta `401` o `403`.
La configurazione di un'integrazione per `$connect` è facoltativa. È opportuno valutare la configurazione di un'integrazione `$connect` se:
+ Si desidera consentire ai client di specificare sottoprotocolli utilizzando il campo `Sec-WebSocket-Protocol`. Per il codice di esempio, consulta [Imposta una `$connect` route che richiede un WebSocket sottoprotocollo](websocket-connect-route-subprotocol.md).
+ Desideri ricevere una notifica in caso di connessione dei client.
+ Desideri limitare le connessioni o controllare chi si connette.
+ Desideri che il back-end invii messaggi ai client utilizzando un URL di callback.
+ Desideri archiviare ogni ID connessione e altre informazioni in un database (ad esempio Amazon DynamoDB).
## Passaggio delle informazioni di connessione dalla route `$connect`
È possibile utilizzare integrazioni proxy e non proxy per passare informazioni dall'instradamento `$connect` a un database o a un altro Servizio AWS.
### Per passare le informazioni di connessione utilizzando un'integrazione proxy
È possibile accedere alle informazioni di connessione da un'integrazione proxy Lambda nell'evento. Usa un'altra AWS Lambda funzione Servizio AWS or per postare sulla connessione.
La seguente funzione Lambda mostra come utilizzare l'oggetto `requestContext` per registrare l'ID di connessione, il nome di dominio, il nome della fase e le stringhe di query.
------
#### [ 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}
```
------
### Per passare informazioni di connessione utilizzando un'integrazione proxy
+ È possibile accedere alle informazioni di connessione da un'integrazione non proxy. Configura la richiesta di integrazione e fornisci un modello di richiesta WebSocket API. Il seguente modello di mappatura [Velocity Template Language (VTL)](https://velocity.apache.org/engine/devel/vtl-reference.html) fornisce una richiesta di integrazione. Questa richiesta invia i seguenti dettagli a un'integrazione non proxy:
+ ID connessione
+ Domain name (Nome dominio)
+ Nome fase
+ Path
+ Headers
+ Stringhe di query
Questa richiesta invia l'ID di connessione, il nome di dominio, il nome della fase i percorsi, le intestazioni e le stringhe di query a un'integrazione non proxy.
```
{
"connectionId": "$context.connectionId",
"domain": "$context.domainName",
"stage": "$context.stage",
"params": "$input.params()"
}
```
Per ulteriori informazioni sulla configurazione delle trasformazioni di dati, consulta [Trasformazioni dei dati per API WebSocket APIs Gateway](websocket-api-data-transformations.md).
Per completare la richiesta di integrazione, impostare `StatusCode: 200` per la risposta di integrazione. Per ulteriori informazioni sulla configurazione di una risposta di integrazione, consulta [Configurazione di una risposta di integrazione mediante la console API Gateway](apigateway-websocket-api-integration-responses.md#apigateway-websocket-api-integration-response-using-console).
## Instradamento `$disconnect`
La route `$disconnect` viene eseguita dopo la chiusura della connessione.
La connessione può essere chiusa dal server o dal client. Poiché la connessione è già chiusa quando viene eseguita, `$disconnect` è un evento best-effort. API Gateway farà il massimo per consegnare l'evento `$disconnect` all'integrazione, ma non può garantire la consegna.
Il back-end è in grado di avviare la disconnessione utilizzando l'API `@connections`. Per ulteriori informazioni, consulta [Utilizzo di comandi `@connections` nel servizio di back-end](apigateway-how-to-call-websocket-api-connections.md).
# Invocazione dell'integrazione backend con l'instradamento `$default` e gli instradamenti personalizzati in Gateway API
La sezione seguente descrive come richiamare l'integrazione del backend utilizzando la `$default` route o una route personalizzata per un' WebSocket API.
**Topics**
+ [Utilizzo di instradamenti per elaborare messaggi](#apigateway-websocket-api-overview-routes)
+ [Instradamento `$default`](#apigateway-websocket-api-routes-about-default)
+ [Instradamenti personalizzati](#apigateway-websocket-api-routes-about-custom)
+ [Utilizzo delle integrazioni WebSocket API Gateway per connettersi alla logica aziendale](#apigateway-websocket-api-overview-integrations)
+ [Differenze importanti tra WebSocket APIs e REST APIs](#apigateway-websocket-api-overview-integrations-differences)
## Utilizzo di instradamenti per elaborare messaggi
In API Gateway WebSocket APIs, i messaggi possono essere inviati dal client al servizio di backend e viceversa. A differenza del request/response modello HTTP, WebSocket nel backend è possibile inviare messaggi al client senza che il client intraprenda alcuna azione.
I messaggi possono essere JSON o non JSON. Tuttavia, solo i messaggi JSON possono essere instradati a integrazioni specifiche in base al contenuto del messaggio. I messaggi non JSON vengono trasmessi al back-end dalla route `$default`.
**Nota**
API Gateway supporta payload dei messaggi fino a 128 KB con dimensione del frame massima di 32 KB. Se un messaggio supera i 32 KB, occorre suddividerlo in più frame, ciascuno di 32 KB o più piccolo. Se si riceve un messaggio (o frame) di dimensioni maggiori, la connessione viene chiusa con codice 1009.
Al momento i payload binari non sono supportati. Se si riceve un frame binario, la connessione viene chiusa con codice 1003. Tuttavia, è possibile convertire i payload binari in testo. Per informazioni, consulta [Tipi di supporti binari per API WebSocket in Gateway API](websocket-api-develop-binary-media-types.md).
Con WebSocket APIs API Gateway, i messaggi JSON possono essere instradati per eseguire un servizio di backend specifico basato sul contenuto del messaggio. Quando un client invia un messaggio tramite la sua WebSocket connessione, ciò si traduce in una *richiesta di routing all'API*. WebSocket La richiesta verrà associata alla route con la chiave route corrispondente in API Gateway. Puoi configurare una richiesta di routing per un' WebSocket API nella console API Gateway AWS CLI, utilizzando o utilizzando un AWS SDK.
**Nota**
Infine AWS SDKs, puoi creare percorsi prima o dopo aver creato le integrazioni. AWS CLI Attualmente la console non supporta il riutilizzo di integrazioni, perciò è necessario creare la route prima e quindi creare l'integrazione per tale route.
Puoi configurare API Gateway per eseguire la convalida su una route prima di passare alla richiesta di integrazione. Se la convalida fallisce, API Gateway fallisce la richiesta senza chiamare il backend, invia al client una risposta del `"Bad request body"` gateway simile alla seguente e pubblica i risultati della convalida in Logs: CloudWatch
```
{"message" : "Bad request body", "connectionId": "{connectionId}", "messageId": "{messageId}"}
```
Ciò consente di ridurre le chiamate non necessarie al back-end e concentrarsi sugli altri requisiti dell'API.
Puoi anche definire una risposta di instradamento per le route dell'API per abilitare la comunicazione bidirezionale. Una risposta di instradamento descrive quali dati verranno inviati al client al termine dell'integrazione di una particolare route. Non è necessario definire una risposta per una route se, ad esempio, desideri che un client invii messaggi al back-end senza ricevere una risposta (comunicazione unidirezionale). Tuttavia, se non fornisci una risposta di instradamento, API Gateway non invierà informazioni sul risultato dell'integrazione ai client.
## Instradamento `$default`
Ogni API WebSocket API Gateway può avere un `$default` percorso. Si tratta di un valore di instradamento speciale che può essere utilizzato nei seguenti modi:
+ Puoi usarlo insieme a chiavi di route definite per specificare una route di "fallback", ad esempio un'integrazione fittizia generica che restituisce un determinato messaggio di errore, per i messaggi in ingresso che non corrispondono ad alcuna delle chiavi di route definite.
+ Puoi utilizzarlo senza alcuna chiave route definita, per specificare un modello di proxy che delega l'instradamento a un componente di back-end.
+ Puoi utilizzarlo per specificare una route per payload non JSON.
## Instradamenti personalizzati
Se desideri invocare un'integrazione specifica in base al contenuto del messaggio, puoi farlo creando una route personalizzata.
Una route personalizzata utilizza una chiave route e l'integrazione specificati dall'utente. Quando un messaggio in entrata contiene una proprietà JSON e tale proprietà valuta un valore che corrisponde al valore della chiave route, API Gateway richiama l'integrazione. (Per ulteriori informazioni, consulta [Panoramica di WebSocket APIs in API Gateway](apigateway-websocket-api-overview.md).)
Ad esempio, supponiamo che tu voglia creare un'applicazione chat room. Potresti iniziare creando un' WebSocket API la cui espressione di selezione del percorso è`$request.body.action`. Potresti quindi definire due route: `joinroom` e `sendmessage`. Un'app client potrebbe richiamare la route `joinroom` inviando un messaggio del tipo seguente:
```
{"action":"joinroom","roomname":"developers"}
```
E potrebbe richiamare la route `sendmessage` inviando un messaggio del tipo seguente:
```
{"action":"sendmessage","message":"Hello everyone"}
```
## Utilizzo delle integrazioni WebSocket API Gateway per connettersi alla logica aziendale
Dopo aver impostato un percorso per un'API WebSocket API Gateway, devi specificare l'integrazione che desideri utilizzare. Come nel caso di una route, per la quale è possibile avere una richiesta di instradamento e una risposta di instradamento, un'integrazione può avere una *richiesta di integrazione* e una *risposta di integrazione*. Una *richiesta di integrazione* contiene le informazioni previste dal back-end per elaborare la richiesta proveniente dal client. Una *risposta di integrazione* contiene i dati restituiti dal back-end ad API Gateway e che possono essere utilizzati per costruire un messaggio da inviare al cliente (se è definita una risposta di instradamento).
Per ulteriori informazioni sulla configurazione di integrazioni, consulta [Integrazioni per API WebSocket APIs Gateway](apigateway-websocket-api-integrations.md).
## Differenze importanti tra WebSocket APIs e REST APIs
Le integrazioni per WebSocket APIs sono simili alle integrazioni per REST APIs, ad eccezione delle seguenti differenze:
+ Al momento, nella console API Gateway è necessario creare prima una route e quindi un'integrazione come destinazione di tale route. Tuttavia, nell'API e nella CLI, puoi creare route e integrazioni in modo indipendente, in qualsiasi ordine.
+ Puoi utilizzare una singola integrazione per più route. Ad esempio, se disponi di un set di operazioni tra loro strettamente correlate, puoi fare in modo che tutte queste route vadano in una singola funzione Lambda. Anziché definire più volte i dettagli dell'integrazione, puoi specificarla una sola volta e assegnarla a ciascuna delle route correlate.
**Nota**
Attualmente la console non supporta il riutilizzo di integrazioni, perciò è necessario creare la route prima e quindi creare l'integrazione per tale route.
Infine AWS SDKs, puoi riutilizzare un'integrazione impostando la destinazione del percorso su un valore di`"integrations/{integration-id}"`, dove `{integration-id}"` è l'ID univoco dell'integrazione da associare alla rotta. AWS CLI
+ API Gateway fornisce più [espressioni di selezione](apigateway-websocket-api-selection-expressions.md) che puoi utilizzare nelle route e nelle integrazioni. Non è necessario basarsi sul tipo di contenuto per selezionare un modello di input o una mappatura di output. Analogamente alle espressioni di selezione della route, puoi definire un'espressione di selezione che deve essere valutata da API Gateway per scegliere l'elemento corretto. Tutte verranno ripristinati al modello `$default` se non viene trovato un modello corrispondente.
+ Nelle richieste di integrazione, l'espressione di selezione del modello supporta `$request.body.` e valori statici.
+ Nelle risposte di integrazione, l'espressione di selezione del modello supporta `$request.body.`, `$integration.response.statuscode`, `$integration.response.header.` e valori statici.
Nel protocollo HTTP, in cui richieste e risposte vengono inviate in maniera sincrona, la comunicazione è essenzialmente unidirezionale. Nel WebSocket protocollo, la comunicazione è bidirezionale. Le risposte sono asincrone e non vengono necessariamente ricevute dal client nello stesso ordine di invio dei messaggi del client. Inoltre, il back-end può inviare messaggi al client.
**Nota**
Per una route configurata per utilizzare l'integrazione `AWS_PROXY` o `LAMBDA_PROXY`, la comunicazione è unidirezionale e API Gateway non trasferisce automaticamente la risposta del back-end alla risposta di instradamento. Ad esempio, in caso dell'integrazione `LAMBDA_PROXY`, il corpo restituito dalla funzione Lambda non verrà restituito al client. Se desideri che il client riceva risposte di integrazione, devi definire una risposta di instradamento per rendere possibile la comunicazione bidirezionale.
# WebSocket espressioni di selezione
API Gateway usa espressioni di selezione per valutare il contesto delle richieste e delle risposte e produrre una chiave. La chiave viene quindi utilizzata per selezionare da un set di valori possibili, in genere fornito da te, lo sviluppatore dell'API. L'esatto set di variabili supportate varierà a seconda del tipo di espressione. Ogni espressione viene descritta in modo dettagliato di seguito.
Per tutte le espressioni, il linguaggio segue lo stesso set di regole:
+ Una variabile ha il prefisso `"$"`.
+ Le parentesi graffe possono essere utilizzate per definire i limiti delle variabili in modo esplicito, ad esemp., `"${request.body.version}-beta"`.
+ Sono supportate numerose variabili, ma la valutazione viene eseguita una sola volta (non esiste la valutazione ricorsiva).
+ Il segno di dollaro (`$`) può essere preceduto dal carattere di escape `"\"`. Questa prassi è molto utile quando si definisce un'espressione associata alla chiave riservata `$default`, ad esempio `"\$default"`.
+ In alcuni casi, un formato di modello è obbligatorio. In questo caso, l'espressione deve essere racchiusa tra barre (`"/"`), ad esempio `"/2\d\d/"` per corrispondere ai codici di stato `2XX`.
**Topics**
+ [Espressioni di selezione della risposta di instradamento](#apigateway-websocket-api-route-response-selection-expressions)
+ [Espressioni di selezione della chiave API](#apigateway-websocket-api-apikey-selection-expressions)
+ [Espressioni di selezione della mappatura dell'API](#apigateway-websocket-api-mapping-selection-expressions)
+ [WebSocket riepilogo delle espressioni di selezione](#apigateway-websocket-api-selection-expression-table)
## Espressioni di selezione della risposta di instradamento
Una [risposta di instradamento](apigateway-websocket-api-route-response.md) viene utilizzata per modellare una risposta dal back-end al client. Infatti WebSocket APIs, una risposta di percorso è facoltativa. Una volta definito, segnala ad API Gateway che deve restituire una risposta a un client dopo aver ricevuto un WebSocket messaggio.
La valutazione dell'*espressione di selezione della risposta di instradamento* produce una chiave di risposta di instradamento. Infine, la chiave viene utilizzata per scegliere tra una delle [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) associate all'API. Tuttavia, al momento è supportata solo la chiave `$default`.
## Espressioni di selezione della chiave API
Questa espressione viene valutata quando il servizio stabilisce che la richiesta specifica deve procedere solo se il client fornisce una [chiave API](api-gateway-basic-concept.md#apigateway-definition-api-key) valida.
Attualmente, i soli due valori supportati sono `$request.header.x-api-key` e `$context.authorizer.usageIdentifierKey`.
## Espressioni di selezione della mappatura dell'API
Questa espressione viene valutata per determinare quale fase API viene selezionata quando viene effettuata una richiesta utilizzando un dominio personalizzato.
Attualmente, l'unico valore supportato è `$request.basepath`.
## WebSocket riepilogo delle espressioni di selezione
La tabella seguente riassume i casi d'uso delle espressioni di selezione in WebSocket APIs:
| Espressione di selezione | Restituisce la chiave per | Note | Esempio di caso d'uso |
| --- | --- | --- | --- |
| Api.RouteSelectionExpression | Route.RouteKey | \$1defaultLa chiave è supportata come instradamento catch-all. | WebSocket Indirizza i messaggi in base al contesto della richiesta di un client. |
| Route.ModelSelectionExpression | Chiave per Route.RequestModels | Facoltativo. Se fornita per un'integrazione non proxy, viene effettuata la convalida del modello. `$default`La chiave è supportata come catch-all. | Convalida dinamica della richiesta all'interno dello stesso instradamento. |
| Integration.TemplateSelectionExpression | Chiave per Integration.RequestTemplates | Facoltativo. Può essere fornita per un'integrazione non proxy allo scopo di manipolare i payload in entrata. `${request.body.jsonPath}`Sono supportati e valori statici. `$default`La chiave è supportata come catch-all. | Manipolazione della richiesta dell'intermediario in base alle proprietà dinamiche della richiesta. |
| Integration.IntegrationResponseSelectionExpression | IntegrationResponse.IntegrationResponseKey | Facoltativo. Può essere fornita per un'integrazione non proxy. Agisce da corrispondenza di modello per i messaggi di errore (da Lambda) o i codici di stato (da integrazioni HTTP). `$default`È necessaria la chiave per far sì che le integrazioni non proxy agiscano da catch-all per le risposte con esito positivo. | Manipolazione della risposta del back-end. Scegliere l'azione da eseguire in base alla risposta dinamica del back-end, ad esempio la gestione distinta di determinati errori. |
| IntegrationResponse.TemplateSelectionExpression | Chiave per IntegrationResponse.ResponseTemplates | Facoltativo. Può essere fornita per un'integrazione non proxy. La chiave \$1default è supportata. | In alcuni casi, una proprietà dinamica della risposta potrebbe imporre trasformazioni differenti all'interno dello stesso instradamento e dell'integrazione associata. `${request.body.jsonPath}`, `${integration.response.statuscode}`, `${integration.response.header.headerName}`, `${integration.response.multivalueheader.headerName}`, Sono supportati , , , e valori statici. `$default`La chiave è supportata come catch-all. |
| Route.RouteResponseSelectionExpression | RouteResponse.RouteResponseKey | Dovrebbero essere forniti per avviare una comunicazione bidirezionale per un WebSocket percorso. Attualmente, questo valore è limitato solo a `$default`. | |
| RouteResponse.ModelSelectionExpression | Chiave per RouteResponse.RequestModels | Attualmente non è supportata. | |