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
È 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
La versione AWS SDK for 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
La AWS SDK for 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
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
È 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)
