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à.
Dopo aver creato l'API, è necessario distribuirla per renderla chiamabile dagli utenti.
Per distribuire un'API, crea una distribuzione API e associala a una fase. Una fase è un riferimento logico a uno stato del ciclo di vita dell'API (ad esempio, dev, prod, beta, v2). Le fasi API sono identificate dall'ID API e dal nome della fase. Sono incluse nell'URL utilizzato per richiamare l'API. Ogni fase è un riferimento con nome a una distribuzione dell'API e viene resa disponibile per le applicazioni client da chiamare.
Importante
Ogni volta che si aggiorna un'API, è necessario distribuire nuovamente l'API in una fase esistente o in una nuova fase. L'aggiornamento di un'API include la modifica di instradamenti, metodi, integrazioni, sistemi di autorizzazione, policy delle risorse e qualsiasi altra cosa diversa dalle impostazioni di fase.
Con l'evoluzione dell'API, puoi continuare a distribuirla in fasi diverse come versioni differenti. Puoi inoltre distribuire gli aggiornamenti API come una distribuzione di una release Canary. Ciò consente ai client API di accedere, sulla stessa fase, alla versione di produzione tramite la release e alla versione aggiornata tramite la release Canary.
Per chiamare un'API distribuita, il client invia una richiesta all'URL di un'API. L'URL è determinato dal protocollo di un'API (HTTP (S) o (WSS)), dal nome host, dal nome della fase e (per REST APIs) dal percorso della risorsa. Il nome host e il nome della fase determinano l'URL di base dell'API.
Se, ad esempio, si utilizza il nome di dominio predefinito dell'API, il formato dell'URL di base di un'API REST (ad esempio) in una fase specifica ({stageName}
https://{restapi-id}.execute-api.{region}.amazonaws.com/{stageName}
Per rendere più intuitivo l'URL di base predefinito dell'API, puoi creare un nome di dominio personalizzato (ad esempio, api.example.com) per sostituire il nome host predefinito dell'API. Per supportare più elementi APIs con il nome di dominio personalizzato, è necessario mappare una fase API su un percorso di base.
Con il nome di dominio personalizzato {api.example.com}{basePath}
https://{api.example.com}/{basePath}
Per ogni fase puoi ottimizzare le prestazioni dell'API impostando i limiti di throttling predefiniti delle richieste a livello di account e abilitando il caching dell'API. Puoi anche abilitare la registrazione delle chiamate API verso CloudTrail o CloudWatch e selezionare un certificato client per il backend per autenticare le richieste API. Inoltre, puoi ignorare le impostazioni a livello di fase per i singoli metodi e definire le variabili di fase per il passaggio di contesti di ambiente specifici della fase all'integrazione API al runtime.
Le fasi permettono un efficace controllo delle versioni dell'API. Ad esempio, puoi distribuire un'API in una fase test e una fase prod e utilizzare la fase test come build di test e la fase prod come build stabile. Dopo che gli aggiornamenti hanno superato il test, puoi promuovere la fase test alla fase prod. La promozione può essere eseguita implementando nuovamente l'API nella fase prod o aggiornando il valore di una variabile di fase dal nome test al nome prod.
In questa sezione viene illustrato come distribuire un'API utilizzando la console API Gateway
Argomenti
