Interceptores HTTP - AWS SDK for Go v2

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Interceptores HTTP

Puede usar interceptores para conectarse a la ejecución de las solicitudes y respuestas de la API. Los interceptores son mecanismos abiertos en los que el SDK llama al código que escribe para inyectar un comportamiento en el ciclo de vida de las solicitudes o respuestas. De esta forma puede modificar una solicitud en tránsito, depurar el procesamiento de las solicitudes, ver las excepciones y mucho más.

Interceptores frente a middleware

AWS SDK for Go v2 proporciona tanto interceptores como middleware para personalizar el procesamiento de las solicitudes. Si bien ambos cumplen propósitos similares, están pensados para diferentes audiencias y casos de uso:

  • Los interceptores están diseñados para los usuarios del SDK que desean personalizar el procesamiento de solicitudes y respuestas con una API sencilla y centrada en HTTP. Proporcionan puntos de enlace específicos en el ciclo de vida de las solicitudes y trabajan directamente con las solicitudes y las respuestas HTTP.

  • El middleware es un sistema más avanzado e independiente del transporte que el SDK utiliza principalmente de forma interna. Si bien es potente, el middleware requiere un conocimiento más profundo de los aspectos internos del SDK e implica interfaces más complejas.

Las principales ventajas de los interceptores respecto al middleware para los casos de uso habituales son las siguientes:

  • Centrados en HTTP: los interceptores trabajan directamente con las solicitudes y las respuestas HTTP, lo que elimina la necesidad de comprobar el tipo de transporte que requiere el middleware.

  • Interfaces más sencillas: cada enlace de interceptor tiene una interfaz específica y centrada, en lugar del patrón de middleware genérico.

  • Modelo de ejecución más claro: los interceptores se ejecutan en puntos bien definidos del ciclo de vida de las solicitudes sin necesidad de conocer la ordenación de pila del middleware.

nota

Los interceptores se basan en el sistema de middleware existente, por lo que ambos pueden coexistir en la misma aplicación. El middleware sigue estando disponible para casos de uso avanzados que requieren un comportamiento independiente del transporte o una manipulación compleja de la pila.

Enlaces de interceptor disponibles

AWS SDK for Go v2 proporciona enlaces de interceptor en varias etapas del ciclo de vida de las solicitudes. Cada enlace corresponde a una interfaz específica que puede implementar:

  • BeforeExecution: primer enlace al que se llama durante la ejecución de la operación

  • BeforeSerialization: antes de que el mensaje de entrada se serialice en una solicitud de transporte

  • AfterSerialization: después de que el mensaje de entrada se serialice en una solicitud de transporte

  • BeforeRetryLoop: antes de entrar en el bucle de reintentos

  • BeforeAttempt: primer enlace al que se llama dentro del bucle de reintentos

  • BeforeSigning: antes de firmarse la solicitud de transporte

  • AfterSigning: después de firmarse la solicitud de transporte

  • BeforeTransmit: antes de enviarse la solicitud de transporte

  • AfterTransmit: después de recibir la respuesta del transporte

  • BeforeDeserialization: antes de deserializar la respuesta del transporte

  • AfterDeserialization: después de deserializar la respuesta del transporte

  • AfterAttempt: último enlace al que se llama dentro del bucle de reintentos

  • AfterExecution: último enlace al que se llama durante la ejecución de la operación

Puede implementar varias interfaces en un solo interceptor para conectarse a varias etapas del ciclo de vida de las solicitudes.

Registro de interceptores

Los interceptores se registran cuando se crea un cliente de servicio o cuando se anula la configuración de una operación específica. El registro varía en función de si desea que el interceptor se aplique a todas las operaciones de su cliente o solo a operaciones específicas.

Los interceptores se administran a través de un registro de interceptores en el que se proporcionan métodos para agregar y eliminar interceptores. En el siguiente ejemplo se muestra un interceptor sencillo que agrega un encabezado de ID de rastro AWS X-Ray a las solicitudes salientes antes del proceso de firma:

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

El registro de interceptores se agrega a las opciones de cliente, lo que permite la configuración del interceptor por operación:

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

Configuración global del interceptor

También puede registrar interceptores a nivel global mediante la función config.LoadDefaultConfig con las opciones With* adecuadas para cada tipo de interceptor. Esto aplica el interceptor a todos los clientes de servicio de AWS creados a partir de esa configuración:

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)