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à.
Crea percorsi per HTTP APIs in API Gateway
Esegui il routing delle richieste API in entrata dirette alle risorse di back-end. Le route sono costituite da due parti: un metodo HTTP e un percorso delle risorse, ad esempi, GET /pets. È possibile definire metodi HTTP specifici per il percorso. In alternativa, è possibile utilizzare il metodo ANY per abbinare tutti i metodi non definiti per una risorsa. È possibile creare una route $default che funga da catch-all per le richieste che non corrispondono ad altre route.
Nota
Gateway Amazon API decodifica i parametri di richiesta con codifica URL prima di passarli all'integrazione back-end.
Lavorare con le variabili di percorso
Nelle route delle API HTTP è possibile utilizzare delle variabili di percorso.
Ad esempio, il percorso GET /pets/{petID} cattura una richiesta GET inviata da un client https://. api-id.execute-api.us-east-2.amazonaws.com/pets/6
Una variabile di percorso greedy cattura tutte le risorse figlio di un percorso. Per creare una variabile di percorso greedy, aggiungere + al nome della variale, ad esempio {proxy+}. La variabile di percorso greedy deve trovarsi alla fine del percorso della risorsa.
Utilizzo dei parametri della stringa di query
Per impostazione predefinita, API Gateway invia i parametri della stringa di query all'integrazione back-end se sono inclusi in una richiesta a un oggetto API HTTP.
Ad esempio, quando un client invia una richiesta a https://, i parametri della stringa di query api-id.execute-api.us-east-2.amazonaws.com/pets?id=4&type=dog?id=4&type=dog vengono inviati all'integrazione.
Lavorare con il percorso $default
Il percorso $default cattura le richieste che non corrispondono esplicitamente ad altri percorsi nell'API.
Quando la route $default riceve una richiesta, API Gateway invia il percorso completo della richiesta all'integrazione. Ad esempio, è possibile creare un'API con solo un percorso $default e integrarlo nel metodo ANY con l'endpoint https://petstore-demo-endpoint.execute-api.com HTTP. Quando si invia una richiesta a https://, API Gateway invia una richiesta a api-id.execute-api.us-east-2.amazonaws.com/store/checkouthttps://petstore-demo-endpoint.execute-api.com/store/checkout.
Per ulteriori informazioni sulle integrazioni HTTP, consultare Crea integrazioni proxy HTTP per HTTP APIs.
Routing delle richieste API
Quando un client invia una richiesta API, API Gateway stabilisce innanzitutto a quale fase instradare la richiesta. Se la richiesta corrisponde esplicitamente a una fase, API Gateway invia la richiesta a tale fase. Se nessuna fase corrisponde completamente alla richiesta, API Gateway invia la richiesta alla fase $default. Se non è presente alcuna $default fase, l'API restituisce {"message":"Not
Found"} e non genera CloudWatch log.
Dopo aver selezionato una fase, API Gateway seleziona una route. API Gateway seleziona la route con la corrispondenza più specifica, utilizzando le seguenti priorità:
Corrispondenza completa per un percorso e un metodo.
Corrispondenza per un percorso e un metodo con una variabile di percorso greedy (
{proxy+}).Instradamento
$default.
Se nessuna route corrisponde a una richiesta, API Gateway restituisce al client il valore {"message":"Not Found"}.
Ad esempio, si consideri un'API con una fase $default e le seguenti route di esempio:
GET /pets/dog/1GET /pets/dog/{id}GET /pets/{proxy+}ANY /{proxy+}$defaultNella tabella seguente viene riepilogato il modo in cui API Gateway instrada le richieste alle route di esempio.
| Richiesta | Percorso selezionato | Spiegazione |
|---|---|---|
|
|
|
La richiesta corrisponde completamente a questo instradamento statico. |
|
|
|
La richiesta corrisponde completamente a questo percorso. |
|
|
|
La richiesta non corrisponde completamente a un percorso. Il percorso con un metodo |
|
|
Il metodo |