HTTP-Interzeptoren - AWS SDK for Go v2
Interzeptoren im Vergleich zu MiddlewareVerfügbare Interceptor-HooksRegistrierung des InterceptorsGlobale Interceptor-Konfiguration

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

HTTP-Interzeptoren

Sie können Interzeptoren verwenden, um sich in die Ausführung von API-Anfragen und -Antworten einzuklinken. Interzeptoren sind offene Mechanismen, bei denen das SDK Code aufruft, den Sie schreiben, um Verhalten in den Lebenszyklus einzufügen. request/response Auf diese Weise können Sie eine In-Flight-Anfrage ändern, die Anforderungsverarbeitung debuggen, Ausnahmen anzeigen und vieles mehr.

Interzeptoren im Vergleich zu Middleware

Die AWS SDK for Go Version 2 bietet sowohl Interzeptoren als auch Middleware zur Anpassung der Anforderungsverarbeitung. Beide dienen zwar ähnlichen Zwecken, sind jedoch für unterschiedliche Zielgruppen und Anwendungsfälle konzipiert:

  • Interceptors wurden für SDK-Benutzer entwickelt, die die request/response Verarbeitung mit einer einfachen, HTTP-orientierten API anpassen möchten. Sie bieten spezifische Anknüpfungspunkte im Anforderungslebenszyklus und arbeiten direkt mit HTTP-Anfragen und -Antworten.

  • Middleware ist ein fortschrittlicheres, transportunabhängiges System, das hauptsächlich intern vom SDK verwendet wird. Middleware ist zwar leistungsstark, erfordert jedoch tiefere Kenntnisse der internen Funktionen des SDK und beinhaltet komplexere Schnittstellen.

Hauptvorteile von Interceptoren gegenüber Middleware für allgemeine Anwendungsfälle:

  • HTTP-orientiert: Interceptoren arbeiten direkt mit HTTP-Anfragen und -Antworten, wodurch die für Middleware erforderliche Überprüfung des Transporttyps entfällt.

  • Einfachere Schnittstellen: Jeder Interceptor-Hook hat eine spezifische, fokussierte Schnittstelle und nicht das generische Middleware-Muster.

  • Klareres Ausführungsmodell: Interceptoren werden an genau definierten Punkten im Anforderungszyklus ausgeführt, ohne dass Kenntnisse über die Reihenfolge der Middleware-Stacks erforderlich sind.

Anmerkung

Interceptors bauen auf dem vorhandenen Middleware-System auf, sodass beide in derselben Anwendung koexistieren können. Middleware ist weiterhin für fortgeschrittene Anwendungsfälle verfügbar, die transportunabhängiges Verhalten oder komplexe Stack-Manipulation erfordern.

Verfügbare Interceptor-Hooks

Die AWS SDK for Go Version 2 bietet Interceptor-Hooks in verschiedenen Phasen des Anforderungslebenszyklus. Jeder Hook entspricht einer bestimmten Schnittstelle, die Sie implementieren können:

  • BeforeExecution- Erster Hook, der während der Ausführung des Vorgangs aufgerufen wird

  • BeforeSerialization— Bevor die Eingabenachricht in eine Transportanforderung serialisiert wird

  • AfterSerialization- Nachdem die Eingabenachricht in die Transportanfrage serialisiert wurde

  • BeforeRetryLoop- Vor dem Eintritt in die Wiederholungsschleife

  • BeforeAttempt- Erster Hook, der innerhalb der Wiederholungsschleife aufgerufen wird

  • BeforeSigning- Bevor die Transportanfrage signiert wird

  • AfterSigning- Nachdem die Transportanfrage unterschrieben wurde

  • BeforeTransmit- Bevor die Transportanfrage gesendet wird

  • AfterTransmit- Nach Erhalt der Transportantwort

  • BeforeDeserialization- Bevor die Transportantwort deserialisiert wird

  • AfterDeserialization- Nach dem Demarshalling der Transportreaktion

  • AfterAttempt- Letzter Hook, der innerhalb der Wiederholungsschleife aufgerufen wurde

  • AfterExecution- Letzter Hook, der während der Ausführung der Operation aufgerufen wurde

Sie können mehrere Schnittstellen in einem einzigen Interceptor implementieren, um sich in mehrere Phasen des Anforderungslebenszyklus einzuklinken.

Registrierung des Interceptors

Sie registrieren Interzeptoren, wenn Sie einen Service-Client erstellen oder wenn Sie die Konfiguration für einen bestimmten Vorgang überschreiben. Die Registrierung unterscheidet sich je nachdem, ob Sie möchten, dass der Interceptor für alle Operationen Ihres Clients oder nur für bestimmte Operationen gilt.

Interzeptoren werden über eine Interceptor-Registry verwaltet, die Methoden zum Hinzufügen und Entfernen von Interzeptoren bereitstellt. Das folgende Beispiel zeigt einen einfachen Interceptor, der ausgehenden Anfragen vor dem Signiervorgang einen AWS X-Ray Trace-ID-Header hinzufügt: 

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

Die Interceptor-Registry wird zu den Client-Optionen hinzugefügt, wodurch die Interceptor-Konfiguration pro Vorgang ermöglicht wird: 

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

Globale Interceptor-Konfiguration

Sie können Interzeptoren auch global registrieren, indem Sie die config.LoadDefaultConfig Funktion mit den entsprechenden With* Optionen für jeden Interzeptortyp verwenden. Dadurch wird der Interceptor auf alle AWS Service-Clients angewendet, die mit dieser Konfiguration erstellt wurden: 

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)