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à.

# Intercettori HTTP
<a name="interceptors"></a>

 È possibile utilizzare gli intercettori per agganciarsi all'esecuzione di richieste e risposte API. Gli intercettori sono meccanismi aperti in cui l'SDK richiama il codice scritto dall'utente per inserire il comportamento nel ciclo di vita. request/response In questo modo, puoi modificare una richiesta in corso, eseguire il debug dell'elaborazione delle richieste, visualizzare le eccezioni e altro ancora. 

## Interceptors vs. middleware
<a name="interceptors-vs-middleware"></a>

 La versione AWS SDK per Go 2 fornisce sia intercettori che middleware per personalizzare l'elaborazione delle richieste. Sebbene entrambi abbiano scopi simili, sono progettati per destinatari e casi d'uso diversi: 
+  Gli **Interceptors** sono progettati per gli utenti SDK che desiderano personalizzare l' request/response elaborazione con una semplice API incentrata su HTTP. Forniscono punti di accesso specifici nel ciclo di vita della richiesta e funzionano direttamente con le richieste e le risposte HTTP. 
+  Il **middleware** è un sistema più avanzato, indipendente dal trasporto, utilizzato principalmente internamente dall'SDK. Sebbene potente, il middleware richiede una conoscenza più approfondita degli interni dell'SDK e coinvolge interfacce più complesse. 

 Principali vantaggi degli intercettori rispetto al middleware per i casi d'uso più comuni: 
+  **Incentrato sull'HTTP**: gli intercettori funzionano direttamente con le richieste e le risposte HTTP, eliminando la necessità di controllare il tipo di trasporto richiesto dal middleware. 
+  **Interfacce più semplici: ogni hook interceptor** ha un'interfaccia specifica e mirata anziché il modello middleware generico. 
+  **Modello di esecuzione più chiaro**: gli intercettori vengono eseguiti in punti ben definiti del ciclo di vita della richiesta senza la necessità di conoscere l'ordinamento degli stack del middleware. 

**Nota**  
 Gli interceptor sono basati sul sistema middleware esistente, quindi entrambi possono coesistere nella stessa applicazione. Il middleware rimane disponibile per casi d'uso avanzati che richiedono un comportamento indipendente dal trasporto o una manipolazione complessa dello stack. 

## Ganci intercettori disponibili
<a name="interceptor-hooks"></a>

 La AWS SDK per Go v2 fornisce ganci di intercettazione in varie fasi del ciclo di vita della richiesta. Ogni hook corrisponde a un'interfaccia specifica che puoi implementare: 
+  `BeforeExecution`- Primo hook chiamato durante l'esecuzione dell'operazione 
+  `BeforeSerialization`- Prima che il messaggio di input venga serializzato nella richiesta di trasporto 
+  `AfterSerialization`- Dopo che il messaggio di input è stato serializzato nella richiesta di trasporto 
+  `BeforeRetryLoop`- Prima di entrare nel ciclo di riprova 
+  `BeforeAttempt`- Primo hook chiamato inside retry loop 
+  `BeforeSigning`- Prima della firma della richiesta di trasporto 
+  `AfterSigning`- Dopo la firma della richiesta di trasporto 
+  `BeforeTransmit`- Prima dell'invio della richiesta di trasporto 
+  `AfterTransmit`- Dopo aver ricevuto la risposta di trasporto 
+  `BeforeDeserialization`- Prima che la risposta al trasporto venga deserializzata 
+  `AfterDeserialization`- Dopo aver riordinato la risposta di trasporto 
+  `AfterAttempt`- Ultimo hook chiamato inside retry loop 
+  `AfterExecution`- Ultimo hook chiamato durante l'esecuzione dell'operazione 

 È possibile implementare più interfacce in un unico intercettore per collegarsi a più fasi del ciclo di vita della richiesta. 

## Registrazione Interceptor
<a name="interceptor-registration"></a>

 Gli intercettori vengono registrati quando si costruisce un client di servizio o quando si sostituisce la configurazione per un'operazione specifica. La registrazione varia a seconda che si desideri che l'interceptor si applichi a tutte le operazioni del client o solo a quelle specifiche. 

 Gli intercettori sono gestiti tramite un registro di intercettori che fornisce metodi per aggiungere e rimuovere gli intercettori. L'esempio seguente mostra un semplice interceptor che aggiunge un'intestazione Trace ID alle richieste in uscita prima del processo di firma: AWS X-Ray 

```
type recursionDetection struct{}

func (recursionDetection) BeforeSigning(ctx context.Context, in *smithyhttp.InterceptorContext) error {
    if traceID := os.Getenv("_X_AMZN_TRACE_ID"); traceID != "" {
        in.Request.Header.Set("X-Amzn-Trace-Id", traceID)
    }
    return nil
}

// use it on the client
svc := s3.NewFromConfig(cfg, func(o *s3.Options) {
    o.Interceptors.AddBeforeSigning(recursionDetection{})
})
```

 Il registro degli intercettori viene aggiunto a Client Options, che consente la configurazione degli intercettori per singola operazione: 

```
// ... or use it per-operation
s3.ListBuckets(context.Background(), &s3.ListBucketsInput{
}, func(o *s3.Options) {
   o.Interceptors.AddBeforeSigning(recursionDetection{})
})
```

## Configurazione globale degli intercettori
<a name="interceptor-global-config"></a>

 È inoltre possibile registrare gli intercettori a livello globale utilizzando la `config.LoadDefaultConfig` funzione con le opzioni appropriate `With*` per ogni tipo di intercettore. Questo applica l'interceptor a tutti i client di servizio creati da quella configurazione: AWS 

```
type myExecutionInterceptor struct{}

func (*myExecutionInterceptor) AfterExecution(ctx context.Context, in *smithyhttp.InterceptorContext) error {
    // Add your custom logic here
    return nil
}

cfg, err := config.LoadDefaultConfig(context.Background(),
    config.WithAfterExecution(&myExecutionInterceptor{}))
if err != nil {
    panic(err)
}

// every service client created from the above config
// will include this interceptor
svc := s3.NewFromConfig(cfg)
```