Intercepteurs HTTP - AWS SDK for Go v2
Intercepteurs et intergicielsCrochets d'interception disponiblesEnregistrement de l'intercepteurConfiguration globale de l'intercepteur

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Intercepteurs HTTP

Vous pouvez utiliser des intercepteurs pour vous connecter à l'exécution des demandes et réponses d'API. Les intercepteurs sont des mécanismes ouverts dans lesquels le SDK appelle le code que vous écrivez pour injecter du comportement dans le request/response cycle de vie. De cette façon, vous pouvez modifier une demande en cours de vol, le traitement d'une demande de débogage, consulter les exceptions, etc.

Intercepteurs et intergiciels

La AWS SDK for Go v2 fournit à la fois des intercepteurs et des intergiciels pour personnaliser le traitement des demandes. Bien que les deux aient des objectifs similaires, ils sont conçus pour des publics et des cas d'utilisation différents :

  • Les intercepteurs sont conçus pour les utilisateurs du SDK qui souhaitent personnaliser le request/response traitement à l'aide d'une API simple axée sur le protocole HTTP. Ils fournissent des points d'accroche spécifiques dans le cycle de vie des demandes et fonctionnent directement avec les requêtes et réponses HTTP.

  • Le middleware est un système plus avancé, indépendant du transport, principalement utilisé en interne par le SDK. Bien que puissant, le middleware nécessite une connaissance approfondie des composants internes du SDK et implique des interfaces plus complexes.

Principaux avantages des intercepteurs par rapport aux intergiciels pour les cas d'utilisation courants :

  • Axé sur le protocole HTTP : les intercepteurs fonctionnent directement avec les requêtes et réponses HTTP, ce qui élimine le besoin de vérifier le type de transport requis par le middleware.

  • Interfaces plus simples : chaque hook d'interception possède une interface spécifique et ciblée plutôt que le modèle générique de middleware.

  • Modèle d'exécution plus clair : les intercepteurs s'exécutent à des moments bien définis du cycle de vie des demandes sans qu'il soit nécessaire de connaître l'ordre des piles d'intergiciels.

Note

Les intercepteurs sont basés sur le système intergiciel existant, de sorte que les deux peuvent coexister dans la même application. Le middleware reste disponible pour les cas d'utilisation avancés nécessitant un comportement indépendant du transport ou une manipulation complexe des piles.

Crochets d'interception disponibles

La AWS SDK for Go v2 fournit des crochets d'interception à différentes étapes du cycle de vie des demandes. Chaque hook correspond à une interface spécifique que vous pouvez implémenter :

  • BeforeExecution- Premier hook appelé lors de l'exécution de l'opération

  • BeforeSerialization- Avant que le message d'entrée ne soit sérialisé dans la demande de transport

  • AfterSerialization- Une fois le message d'entrée sérialisé dans la demande de transport

  • BeforeRetryLoop- Avant d'entrer dans la boucle de nouvelle tentative

  • BeforeAttempt- Premier crochet appelé boucle de réessai intérieure

  • BeforeSigning- Avant la signature de la demande de transport

  • AfterSigning- Après signature de la demande de transport

  • BeforeTransmit- Avant l'envoi de la demande de transport

  • AfterTransmit- Après réception de la réponse du transport

  • BeforeDeserialization- Avant que la réponse au transport ne soit désérialisée

  • AfterDeserialization- Après avoir désorganisé la réponse du transport

  • AfterAttempt- Dernier crochet appelé boucle de réessai intérieure

  • AfterExecution- Dernier hook appelé lors de l'exécution de l'opération

Vous pouvez implémenter plusieurs interfaces dans un seul intercepteur afin de vous connecter à plusieurs étapes du cycle de vie des demandes.

Enregistrement de l'intercepteur

Vous enregistrez des intercepteurs lorsque vous créez un client de service ou lorsque vous remplacez la configuration pour une opération spécifique. L'enregistrement varie selon que vous souhaitez que l'intercepteur s'applique à toutes les opérations pour votre client ou uniquement à des opérations spécifiques.

Les intercepteurs sont gérés via un registre d'intercepteurs qui fournit des méthodes pour ajouter et supprimer des intercepteurs. L'exemple suivant montre un intercepteur simple qui ajoute un en-tête AWS X-Ray trace ID aux demandes sortantes avant le processus de signature : 

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{})
})

Le registre des intercepteurs est ajouté aux options du client, ce qui permet de configurer l'intercepteur par opération : 

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

Configuration globale de l'intercepteur

Vous pouvez également enregistrer les intercepteurs globalement à l'aide de la config.LoadDefaultConfig fonction avec les With* options appropriées pour chaque type d'intercepteur. Cela applique l'intercepteur à tous les clients AWS de service créés à partir de cette configuration : 

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)