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à.
Richiama l'integrazione del backend con $default Route e i percorsi personalizzati in Gateway API
La sezione seguente descrive come richiamare l'integrazione del backend utilizzando la $default route o una route personalizzata per a. WebSocket API
Argomenti
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 HTTP del modello di richiesta/risposta, WebSocket nel backend è possibile inviare messaggi al client senza che il client intraprenda alcuna azione.
I messaggi possono essere JSON o meno. JSON Tuttavia, solo JSON i messaggi possono essere indirizzati a integrazioni specifiche in base al contenuto del messaggio. I messaggi diversi dai JSON messaggi vengono passati al backend tramite il percorso. $default
Nota
APIGateway supporta payload di messaggi fino a 128 KB con una dimensione massima dei frame 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. Consulta Tipi di supporti binari per le WebSocket API in API Gateway.
Con WebSocket APIs in API Gateway, JSON i messaggi possono essere instradati per eseguire un servizio di backend specifico basato sul contenuto dei messaggi. Quando un client invia un messaggio tramite la sua WebSocket connessione, ciò si traduce in una richiesta di routing a. WebSocket API La richiesta verrà abbinata alla route con la chiave di route corrispondente in API Gateway. È possibile impostare una richiesta di route per WebSocket API a 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.
È possibile configurare API Gateway per eseguire la convalida di una richiesta di percorso prima di procedere con la 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ò riduce le chiamate non necessarie al backend e ti consente di concentrarti sugli altri requisiti del tuo. API
Puoi anche definire una risposta di routing per i tuoi percorsi per abilitare API 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 routing, API Gateway non invierà alcuna informazione sul risultato dell'integrazione ai tuoi clienti.
Instradamento $default
Ogni API Gateway WebSocket API 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.
-
È possibile utilizzarlo per specificare un percorso per carichi diversi dai JSON payload.
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 arrivo contiene una JSON proprietà e tale proprietà restituisce un valore che corrisponde al valore della chiave della route, API Gateway richiama l'integrazione. (Per ulteriori informazioni, consulta Panoramica di WebSocket APIs in API Gateway.)
Ad esempio, supponiamo che tu voglia creare un'applicazione chat room. È possibile iniziare creando un'espressione di selezione del percorso WebSocket API la cui espressione è. $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 WebSocket API delle integrazioni API Gateway per connettersi alla logica aziendale
Dopo aver impostato un percorso per un API Gateway WebSocket API, 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 che il backend restituisce a API Gateway e che possono essere utilizzati per costruire un messaggio da inviare al client (se è definita una risposta di routing).
Per ulteriori informazioni sulla configurazione di integrazioni, consulta Integrazioni per WebSocket API in API Gateway.
Differenze importanti tra e WebSocket APIs REST APIs
Le integrazioni per WebSocket APIs sono simili alle integrazioni per RESTAPIs, ad eccezione delle seguenti differenze:
-
Attualmente, nella console API Gateway è necessario creare prima una route e poi creare un'integrazione come destinazione di quella route. Tuttavia, alla API fineCLI, puoi creare percorsi e integrazioni indipendentemente, 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/, dove{integration-id}"{integration-id}" -
APIGateway fornisce più espressioni di selezione che puoi utilizzare nei tuoi percorsi e nelle tue integrazioni. Non è necessario basarsi sul tipo di contenuto per selezionare un modello di input o una mappatura di output. Come per le espressioni di selezione delle rotte, è possibile definire un'espressione di selezione da valutare da API Gateway per scegliere l'elemento giusto. Tutte verranno ripristinati al modello
$defaultse non viene trovato un modello corrispondente.-
Nelle richieste di integrazione, l'espressione di selezione del modello supporta
$request.body.e valori statici.<json_path_expression> -
Nelle risposte di integrazione, l'espressione di selezione del modello supporta
$request.body.,<json_path_expression>$integration.response.statuscode,$integration.response.header.e valori statici.<headerName>
-
Nel HTTP protocollo, in cui le richieste e le risposte vengono inviate in modo sincrono, 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 un percorso configurato per l'uso AWS_PROXY o l'LAMBDA_PROXYintegrazione, la comunicazione è unidirezionale e API Gateway non trasmetterà automaticamente la risposta del backend alla risposta di routing. 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.
