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à.
# Pubblicazione di API HTTP che i clienti possono invocare
Puoi utilizzare fasi e nomi di dominio personalizzati per pubblicare l'API richiamabile dai client.
Una fase API è un riferimento logico a uno stato del ciclo di vita dell'API (ad esempio, `dev`, `prod`, `beta` o `v2`). Ogni fase è un riferimento con nome a una distribuzione dell'API e viene resa disponibile per le applicazioni client da chiamare. Puoi configurare integrazioni e impostazioni differenti per ogni fase di un'API.
Puoi utilizzare nomi di dominio personalizzati per fornire un URL più semplice e intuitivo all'API richiamabile dai client, rispetto all'URL predefini, `https://api-id.execute-api.region.amazonaws.com/stage`.
**Nota**
Per aumentare la sicurezza delle API API Gateway, il dominio `execute-api.{region}.amazonaws.com`è registrato nella [Public Suffix List (PSL)](https://publicsuffix.org/). Per una maggiore sicurezza, consigliamo di utilizzare i cookie con un prefisso `__Host-` se hai bisogno di impostare cookie sensibili nel nome di dominio predefinito per le API API Gateway. Questa pratica ti aiuterà a difendere il tuo dominio dai tentativi CSRF (cross-site request forgery). Per ulteriori informazioni, consulta la pagina [Impostazione cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes) nella pagina Mozilla Developer Network.
**Topics**
+ [Fasi per HTTP APIs in API Gateway](http-api-stages.md)
+ [Politica di sicurezza per HTTP APIs in API Gateway](http-api-ciphers.md)
+ [Nomi di dominio personalizzati per API HTTP in Gateway API](http-api-custom-domain-names.md)
# Fasi per HTTP APIs in API Gateway
Una fase API è un riferimento logico a uno stato del ciclo di vita dell'API (ad esempio, `dev`, `prod`, `beta` o `v2`). Le fasi API sono identificate dal rispettivo ID API e dal nome della fase e 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.
È possibile creare una fase `$default` che viene servita dalla base dell'URL dell'API, ad esempio `https://{api_id}.execute-api.{region}.amazonaws.com/`. Utilizzare questo URL per richiamare una fase API.
Una distribuzione è uno snapshot della configurazione dell'API. Dopo essere stata distribuita a una fase, l'API è disponibile per i client da richiamare. È necessario distribuire un'API per attivare le modifiche apportate. Se si abilitano le distribuzioni automatiche, le modifiche apportate a un'API vengono rilasciate automaticamente.
# Usa le variabili di fase per HTTP APIs in API Gateway
Le variabili di fase sono coppie chiave-valore che è possibile definire per una fase di un'API HTTP. Fungono da variabili di ambiente e possono essere utilizzate nella configurazione dell'API.
Le variabili di fase non sono destinate ad essere utilizzate per i dati sensibili, come le credenziali. Per passare dati sensibili alle integrazioni, usa un AWS Lambda autorizzatore. È possibile passare dati sensibili alle integrazioni nell'output del provider di autorizzazioni Lambda. Per ulteriori informazioni, consulta [Formato della risposta dell'autorizzazione](http-api-lambda-authorizer.md#http-api-lambda-authorizer.payload-format-response).
## Esempio: utilizzo di una variabile di fase per personalizzare l'endpoint di integrazione HTTP
Ad esempio, puoi definire una variabile di fase e quindi impostare il suo valore come un endpoint HTTP per un'integrazione proxy HTTP. Successivamente, puoi fare riferimento all'endpoint utilizzando il nome della variabile di fase associata. In questo modo, puoi utilizzare la stessa configurazione API con un endpoint diverso in ogni fase. Allo stesso modo, puoi utilizzare le variabili di fase per specificare un'integrazione di AWS Lambda funzioni diversa per ogni fase dell'API.
Per utilizzare una variabile di fase per personalizzare l'endpoint di integrazione HTTP, è necessario innanzitutto impostare il nome e il valore della variabile di fase (ad esempio `url`) con un valore pari a `example.com`. Quindi, impostare un'integrazione proxy HTTP. Anziché inserire l'URL dell'endpoint, è possibile comunicare ad API Gateway di usare il valore della variabile di fase, ossi, **http://\$1\$1stageVariables.url\$1**. Questo valore indica ad API Gateway di sostituire la variabile di fase `${}` al runtime, a seconda della fase dell'API.
È possibile fare riferimento alle variabili di fase in modo simile per specificare il nome di una funzione Lambda o un ruolo AWS ARN.
Quando si specifica un nome di funzione Lambda come valore della variabile di fase, è necessario configurare manualmente le autorizzazioni per la funzione Lambda. Il comando [add-permission](https://docs.aws.amazon.com/cli/latest/reference/lambda/add-permission.html) seguente configura l’autorizzazione per la funzione Lambda:
```
aws lambda add-permission --function-name arn:aws:lambda:XXXXXX:your-lambda-function-name --source-arn arn:aws:execute-api:us-east-1:YOUR_ACCOUNT_ID:api_id/*/HTTP_METHOD/resource --principal apigateway.amazonaws.com --statement-id apigateway-access --action lambda:InvokeFunction
```
# Riferimento alle variabili di fase API Gateway per HTTP APIs in API Gateway
È possibile utilizzare le variabili di fase API Gateway per HTTP APIs nei seguenti casi.
## Integrazione HTTP URIs
Puoi utilizzare una variabile di fase come parte di un URI di integrazione HTTP, come mostrato negli esempi seguenti.
+ Un URI completo senza protocoll – `http://${stageVariables.}`
+ Un dominio completo – `http://${stageVariables.}/resource/operation`
+ Un sottodominio – `http://${stageVariables.}.example.com/resource/operation`
+ Un percorso – `http://example.com/${stageVariables.}/bar`
+ Una stringa di query – `http://example.com/foo?q=${stageVariables.}`
## Funzioni Lambda
Puoi utilizzare una variabile di fase al posto di un nome di integrazione di funzione o alias Lambda, come illustrato negli esempi seguenti.
+ `arn:aws:apigateway::lambda:path/2015-03-31/functions/arn:aws:lambda:::function:${stageVariables.}/invocations`
+ `arn:aws:apigateway::lambda:path/2015-03-31/functions/arn:aws:lambda:::function::${stageVariables.}/invocations`
**Nota**
Per utilizzare una variabile di fase per una funzione Lambda, la funzione deve essere nello stesso account dell'API. Le variabili di fase non supportano le funzioni Lambda tra più account.
## AWS credenziali di integrazione
È possibile utilizzare una variabile stage come parte di un ARN di credenziali AWS utente o di ruolo, come illustrato nell'esempio seguente.
+ `arn:aws:iam:::${stageVariables.}`
# Politica di sicurezza per HTTP APIs in API Gateway
Gateway API applica la policy di sicurezza `TLS_1_2` per tutti gli endpoint delle API HTTP.
Una *policy di sicurezza* è una combinazione predefinita di una versione TLS minima e un pacchetto di crittografia offerta da Gateway Amazon API. Il protocollo TLS affronta i problemi di sicurezza della rete, ad esempio manomissioni e intercettazioni tra un client e un server. Quando i client stabiliscono un handshake TLS sull'API tramite il dominio personalizzato, la policy di sicurezza applica la versione di TLS e le opzioni del pacchetto di crittografia che i client possono scegliere di utilizzare. Questa policy di sicurezza accetta il traffico TLS 1.2 e TLS 1.3 e rifiuta il traffico TLS 1.0.
## Protocolli e cifrari TLS supportati per HTTP APIs
La tabella seguente descrive i protocolli TLS supportati per HTTP. APIs
| **Protocolli TLS** | **Policy di sicurezza TLS\$11\$12** |
| --- | --- |
| TLSv13. | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| TLSv12. | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
La tabella seguente descrive i codici TLS disponibili per la politica di sicurezza TLS 1\$12 per HTTP. APIs
| **Crittografie TLS** | **Policy di sicurezza TLS\$11\$12** |
| --- | --- |
| TLS-AES-128-GCM- SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| TLS-AES-256-GCM- SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| TLS- - - CHACHA20 POLY1305 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-ECDSA- -GCM- AES128 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDH-RSA- AES128 -GCM- SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-ECSA AES128 - - SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-RSA- - AES128 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-ECDSA- -GCM AES256 - SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDH-RSA- AES256 -GCM- SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-ECSA AES256 - - SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-RSA- - AES256 SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| AES128-GCM- SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| AES128-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| AES256-GCM- SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| AES256-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
## OpenSSL e nomi crittografia RFC
OpenSSL e IETF RFC 5246 utilizzano nomi diversi per le stesse crittografie. Per l'elenco dei nomi delle crittografie, consulta [OpenSSL e nomi crittografia RFC](apigateway-security-policies-list.md#apigateway-secure-connections-openssl-rfc-cipher-names).
## Informazioni su REST e APIs WebSocket APIs
Per ulteriori informazioni su REST APIs e WebSocket APIs, vedere [Scegli una politica di sicurezza per il tuo dominio personalizzato in API Gateway](apigateway-custom-domain-tls-version.md) e[Politica di sicurezza per WebSocket APIs API Gateway](websocket-api-ciphers.md).
# Nomi di dominio personalizzati per API HTTP in Gateway API
I *nomi di dominio personalizzati* sono URL più semplici e più intuitivi che è possibile fornire agli utenti delle API.
Dopo aver distribuito un'API, tu e i tuoi clienti potete richiamarla usando l'URL di base predefinito nel formato seguente:
```
https://api-id.execute-api.region.amazonaws.com/stage
```
dove *api-id* è generato da Gateway API, *region* è la Regione AWS e *stage* è il valore che è stato specificato al momento dell'implementazione dell'API.
La parte del nome host dell'URL, `api-id.execute-api.region.amazonaws.com`, fa riferimento a un endpoint API. Il nome dell'endpoint API predefinito viene generato casualmente, è complesso da richiamare e non è intuitivo.
Con i nomi di dominio personalizzati, è possibile impostare il nome host dell'API e scegliere un percorso base (ad esempio `myservice`) per mappare l'URL alternativo all'API. Ad esempio, un URL di base dell'API più intuitivo può diventare:
```
https://api.example.com/myservice
```
## Considerazioni
Le seguenti considerazioni potrebbero influire sull'utilizzo di un nome di dominio personalizzato.
+ Un nome di dominio personalizzato regionale può essere associato alle REST API e alle API HTTP. È possibile utilizzare le API di Gateway API Versione 2 per creare e gestire nomi di dominio personalizzati regionali per le REST API.
+ L'unica versione minima di TLS supportata è TLS 1.2.
+ È necessario creare o aggiornare il record di risorse del provider DNS per eseguire la mappatura all'endpoint API. In assenza di questa mappatura, le richieste API destinate al nome di dominio personalizzato non possono raggiungere API Gateway.
+ È possibile supportare un numero pressoché infinito di nomi di dominio senza superare la quota predefinita con un certificato jolly. Per ulteriori informazioni, consulta [Nomi di dominio personalizzati con caratteri jolly](#http-wildcard-custom-domain-names).
## Prerequisiti
Di seguito sono riportati i prerequisiti per la creazione di un nome di dominio personalizzato.
### Registrare un nome di dominio
Per configurare nomi di dominio personalizzati per le API, devi avere un nome di dominio Internet registrato. Puoi registrare un nome di dominio Internet utilizzando [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) oppure un registrar di dominio di terze parti a tua scelta. Il nome di dominio personalizzato può essere il nome di un sottodominio o del dominio root (detto anche "apex di zona") di un dominio Internet registrato.
Il nome di dominio deve seguire la specifica [RFC 1035](https://tools.ietf.org/html/rfc1035#section-2.3.4) e può avere un massimo di 63 ottetti per etichetta e 255 ottetti in totale.
### Certificati per nomi di dominio personalizzati
Prima di configurare un nome di dominio personalizzato per un'API, è necessario che sia già presente un certificato SSL/TLS in ACM. Se ACM non è disponibile nella Regione AWS in cui si sta creando il nome di dominio personalizzato, è necessario importare nella Regione un certificato in Gateway API.
Per importare un certificato SSL/TLS, devi fornire il corpo del certificato SSL/TLS in formato PEM, la sua chiave privata e la catena di certificati per il nome di dominio personalizzato.
Ogni certificato archiviato in ACM è identificato dal relativo ARN. Con i certificati emessi da ACM, non devi preoccuparti di esporre dettagli sensibili del certificato, come la chiave privata. Per usare un certificato gestito da AWS per un nome di dominio, devi semplicemente fare riferimento al relativo ARN.
Se l’applicazione utilizza il blocco dei certificati, talvolta denominato associazione SSL, per associare un certificato ACM, è possibile che l'applicazione non riesca a connettersi al tuo dominio dopo che AWS ha rinnovato il certificato. Per ulteriori informazioni, consulta [Probemi nel blocco dei certificati](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-pinning.html) nella *Guida per l'utente di AWS Certificate Manager*.
## Nomi di dominio personalizzati con caratteri jolly
Con i nomi di dominio personalizzati con caratteri jolly, è possibile supportare un numero quasi infinito di nomi di dominio senza superare la [quota predefinita](limits.md). Ad esempio, è possibile dare a ciascuno dei clienti il proprio nome di dominio, `customername.api.example.com`.
Per creare un nome di dominio personalizzato con caratteri jolly, specificare un carattere jolly (`*`) come primo sottodominio di un dominio personalizzato che rappresenta tutti i possibili sottodomini di un dominio radice.
Ad esempio, il nome di dominio personalizzato con caratteri jolly `*.example.com` genera sottodomini quali `a.example.com`, `b.example.com` e `c.example.com`, indirizzati tutti allo stesso dominio.
I nomi di dominio personalizzati con caratteri jolly supportano configurazioni distinte dai nomi di dominio personalizzati standard di API Gateway. Ad esempio, in un singolo account AWS, è possibile configurare `*.example.com` e `a.example.com` affinché si comportino in modo diverso.
Per creare un nome di dominio personalizzato con caratteri jolly, è necessario fornire un certificato emesso da ACM che sia stato convalidato utilizzando il DNS o il metodo di convalida della posta elettronica.
**Nota**
Non è possibile creare un nome di dominio personalizzato con caratteri jolly se un account AWS diverso ha creato un nome di dominio personalizzato in conflitto con il nome di dominio personalizzato con caratteri jolly. Ad esempio, se l'account A ha creato `a.example.com`, l'account B non può creare il nome di dominio personalizzato con caratteri jolly `*.example.com`.
Se l'account A e l'account B condividono un proprietario, è possibile contattare il [Centro assistenza AWS](https://console.aws.amazon.com/support/home#/) per richiedere un'eccezione.
## Passaggi successivi per nomi di dominio personalizzati
Per configurare un nome di dominio personalizzato per un'API HTTP, consulta la documentazione disponibile nella sezione REST API della Guida per gli sviluppatori di Gateway API.
Per prima cosa, si specifica un certificato per il nome di dominio personalizzato. Per ulteriori informazioni, consulta [Prepara i certificati in AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md). Successivamente, si crea un nome di dominio personalizzato regionale. Per ulteriori informazioni, consulta [Configurazione di un nome di dominio personalizzato regionale in Gateway API](apigateway-regional-api-custom-domain-create.md).
# Mappatura delle fasi API a un nome di dominio personalizzato per le API HTTP
È possibile utilizzare le mappature API per connettere le fasi API a un nome di dominio personalizzato. Dopo aver creato un nome di dominio e aver configurato i record DNS, è possibile utilizzare le mappature API per inviare il traffico alle API tramite il nome di dominio personalizzato.
Una mappatura API specifica un'API, una fase e, facoltativamente, un percorso da utilizzare per la mappatura. Ad esempio, è possibile mappare la fase `production` di un'API su `https://api.example.com/orders`.
È possibile mappare le fasi HTTP e API REST allo stesso nome di dominio personalizzato.
Prima di creare una mappatura API, è necessario disporre di un'API, di una fase e di un nome di dominio personalizzato. Per ulteriori informazioni sulla creazione di un nome di dominio personalizzato, consulta [Configurazione di un nome di dominio personalizzato regionale in Gateway API](apigateway-regional-api-custom-domain-create.md).
## Routing delle richieste API
È possibile configurare le mappature API con più livelli, ad esempio `orders/v1/items` e `orders/v2/items`.
Per mappature API con più livelli, API Gateway instrada le richieste alla mappatura API che ha il percorso corrispondente più lungo. API Gateway considera solo i percorsi configurati per le mappature API, e non i percorsi API, per selezionare l'API da richiamare. Se nessun percorso corrisponde alla richiesta, API Gateway invia la richiesta all'API mappata al percorso vuoto `(none)`.
Per i nomi di dominio personalizzati che usano mappature API con più livelli, API Gateway instrada le richieste alla mappatura API che ha il percorso corrispondente più lungo.
Ad esempio, se si considera un nome di dominio personalizzato `https://api.example.com` con le seguenti mappature API:
1. `(none)` mappato all'API 1.
1. `orders` mappato all'API 2.
1. `orders/v1/items` mappato all'API 3.
1. `orders/v2/items` mappato all'API 4.
1. `orders/v2/items/categories` mappato all'API 5.
| Richiesta | API selezionata | Spiegazione |
| --- | --- | --- |
| `https://api.example.com/orders` | `API 2` | La richiesta corrisponde esattamente a questa mappatura API. |
| `https://api.example.com/orders/v1/items` | `API 3` | La richiesta corrisponde esattamente a questa mappatura API. |
| `https://api.example.com/orders/v2/items` | `API 4` | La richiesta corrisponde esattamente a questa mappatura API. |
| `https://api.example.com/orders/v1/items/123` | `API 3` | API Gateway sceglie la mappatura con il percorso corrispondente più lungo. `123` alla fine della richiesta non influisce sulla selezione. |
| `https://api.example.com/orders/v2/items/categories/5` | `API 5` | API Gateway sceglie la mappatura con il percorso corrispondente più lungo. |
| `https://api.example.com/customers` | `API 1` | API Gateway utilizza la mappatura vuota come catch-all. |
| `https://api.example.com/ordersandmore` | `API 2` | API Gateway sceglie la mappatura con il prefisso corrispondente più lungo. Per un nome di dominio personalizzato configurato con mappature a livello singolo, ad esempio solo `https://api.example.com/orders` e `https://api.example.com/`, API Gateway sceglie `API 1`, poiché non esiste un percorso corrispondente con `ordersandmore`. |
## Restrizioni
+ In una mappatura API, il nome di dominio personalizzato e le API mappate devono trovarsi nello stesso account AWS.
+ Le mappature API devono contenere solo lettere, numeri e i seguenti caratteri: `$-_.+!*'()/`.
+ La lunghezza massima per il percorso in una mappatura API è di 300 caratteri.
+ È possibile disporre di 200 mappature API con più livelli per ogni nome di dominio. Questo limite non include le mappature API con livelli singoli, ad esempio `/prod`.
+ È possibile mappare le API HTTP a un nome di dominio personalizzato regionale solo con la policy di sicurezza TLS 1.2.
+ Non è possibile mappare le API WebSocket allo stesso nome di dominio personalizzato di un'API HTTP o un'API REST.
+ Se si crea una mappatura API con più livelli, Gateway API converte tutti i nomi di intestazione in lettere minuscole.
## Creare una mappatura API
Per creare una mappatura API, innanzitutto è necessario creare un nome di dominio personalizzato, un'API e una fase. Per informazioni sulla creazione di un nome di dominio personalizzato, consulta [Configurazione di un nome di dominio personalizzato regionale in Gateway API](apigateway-regional-api-custom-domain-create.md).
Per modelli di esempio di AWS Serverless Application Model che creano tutte le risorse, consulta [Sessioni con SAM](https://github.com/aws-samples/sessions-with-aws-sam/tree/master/custom-domains) su GitHub.
------
#### [ Console di gestione AWS ]
**Per creare una mappatura API**
1. Accedere alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Scegliere **Nomi di dominio personalizzati**.
1. Selezionare un nome di dominio personalizzato già creato.
1. Scegliere **API mappings (mappature API)**.
1. Scegliere **Configure API mappings (Configura mappature API)**.
1. Scegliere **Add new mapping (Aggiungi nuova mappatura)**.
1. Immettere un'**API**, uno **Stage (Fase)**e, facoltativamente, un **Path (Percorso)**.
1. Selezionare **Salva**.
------
#### [ AWS CLI ]
Il comando [create-api-mapping](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api.html) seguente crea una mappatura API. In questo esempio, API Gateway invia le richieste `api.example.com/v1/orders` all'API e alla fase specificate.
```
aws apigatewayv2 create-api-mapping \
--domain-name api.example.com \
--api-mapping-key v1/orders \
--api-id a1b2c3d4 \
--stage test
```
------
#### [ CloudFormation ]
Il seguente esempio di CloudFormation consente di creare una mappatura API.
```
MyApiMapping:
Type: 'AWS::ApiGatewayV2::ApiMapping'
Properties:
DomainName: api.example.com
ApiMappingKey: 'orders/v2/items'
ApiId: !Ref MyApi
Stage: !Ref MyStage
```
------
# Disabilitazione dell'endpoint predefinito per API HTTP
Per impostazione predefinita, i client possono richiamare l'API utilizzando l'endpoint `execute-api` generato da API Gateway per l'API. Per garantire che i client possano accedere all'API solo utilizzando un nome di dominio personalizzato con l'autenticazione TLS reciproca, disattivare l'endpoint `execute-api` predefinito. Quando si disattiva l'endpoint predefinito, questa operazione influisce su tutte le fasi di un'API.
La seguente procedura mostra come disabilitare l'endpoint predefinito per un'API HTTP.
------
#### [ Console di gestione AWS ]
1. Accedere alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Scegliere un'API HTTP.
1. Scegli l'ID dell'API per aprire la pagina **Dettagli API**.
1. In **Dettagli API** seleziona **Modifica**.
1. Per **Endpoint predefinito** seleziona **Disabilita**.
1. Selezionare **Salva**.
Se si attivano le implementazioni automatiche per la fase, non è necessario implementare nuovamente l'API per rendere effettiva la modifica. In caso contrario, è necessario implementare nuovamente l'API.
1. (Facoltativo) Scegli **Distribuzione**, quindi implementa nuovamente l'API o crea una nuova fase per rendere effettiva la modifica.
------
#### [ AWS CLI ]
Il comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html) seguente disabilita l’endpoint predefinito per un’API HTTP:
```
aws apigatewayv2 update-api \
--api-id abcdef123 \
--disable-execute-api-endpoint
```
Dopo aver disattivato l'endpoint predefinito, è necessario distribuire l'API per rendere effettiva la modifica, a meno che non siano abilitate le distribuzioni automatiche.
Il seguente comando [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-deployment.html) crea l'implementazione:
```
aws apigatewayv2 create-deployment \
--api-id abcdef123 \
--stage-name dev
```
------
# Tipi di indirizzo IP per nomi di dominio personalizzati per API HTTP
Quando si crea un’API, è possibile specificare il tipo di indirizzo IP che può invocare il dominio. È possibile scegliere IPv4 per risolvere gli indirizzi IPv4 per invocare il dominio oppure dualstack per consentire a entrambi gli indirizzi IPv4 e IPv6 di invocare il dominio. È consigliabile impostare il tipo di indirizzo IP su dualstack per ridurre l’esaurimento dello spazio IP o per il livello di sicurezza. Per ulteriori informazioni sui vantaggi del tipo di indirizzo IP dualstack, consultare [IPv6 on AWS](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/internet-protocol-version-6.html).
## Considerazioni sui tipi di indirizzo IP
Le seguenti considerazioni potrebbero influire sull’utilizzo dei tipi di indirizzo IP.
+ Il tipo di indirizzo IP predefinito per i nomi di dominio personalizzati di Gateway API è IPv4.
+ Per il nome di dominio personalizzato, non è necessario che tutte le API mappate ad esso abbiano lo stesso tipo di indirizzo IP. Se si disabilita l’endpoint API predefinito, si potrebbe influire sul modo in cui i chiamanti possono invocare l’API.
## Modifica del tipo di indirizzo IP di un nome di dominio personalizzato
È possibile modificare il tipo di indirizzo IP aggiornando la configurazione dell’endpoint del dominio. È possibile aggiornare la configurazione dell’endpoint del dominio utilizzando la Console di gestione AWS, AWS CLI, CloudFormation o un AWS SDK.
------
#### [ Console di gestione AWS ]
**Per modificare il tipo di indirizzo IP di un nome di dominio personalizzato**
1. Accedere alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Scegliere un nome di dominio personalizzato pubblico.
1. Scegliere **Configurazione endpoint**.
1. Per Tipo di indirizzo IP, selezionare **IPv4** o **Dualstack**.
1. Selezionare **Salva**.
------
#### [ AWS CLI ]
Il comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html) seguente aggiorna un’API in modo che abbia un tipo di indirizzo IP dualstack:
```
aws apigatewayv2 update-domain-name \
--domain-name dualstack.example.com \
--domain-name-configurations CertificateArn=arn:aws:acm:us-east-1:111122223333:certificate/abcd1234-5678-abc,IpAddressType=dualstack
```
L'output sarà simile al seguente:
```
{
"ApiMappingSelectionExpression": "$request.basepath",
"DomainName": "dualstack.example.com",
"DomainNameConfigurations": [
{
"ApiGatewayDomainName": "d-abcd1234.execute-api.us-east-1.amazonaws.com",
"CertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/abcd1234-5678-abc",
"DomainNameStatus": "AVAILABLE",
"EndpointType": "REGIONAL",
"HostedZoneId": "Z3LQWSYCGH4ADY",
"SecurityPolicy": "TLS_1_2",
"IpAddressType": "dualstack"
}
],
"Tags": {}
}
```
------