[ASP.NET WebAPI] Cuando usar un Message Handler y cuando un Filter

Podríamos pensar a simple vista que un message handler y un filter tienen la misma función en WebAPI pero tienen diferentes características y digo esto porque veo algunos ejemplos en que creo que no se hace un uso correcto de ellos.

A continuación os pongo un enlace a un poster de WebAPI para que todo el mundo tenga claro el pipeline de WebAPI:

ASP.NET Web API HTTP Message Lifecycle

Si nos fijamos en el poster podemos observar que los message handlers son invocados al principio y en cada petición del pipeline de WebAPI antes incluso de que se cree una instancia del controlador que corresponda en la petición, por lo cual son ideales en escenarios en los que tengamos que ejecutar algo de lógica que requiera ser ejecutada en cada petición, un ejemplo de ello sería la autenticación. Tenemos la oportunidad de crear una respuesta directamente y evitar que se siga ejecutando el pipeline.

Para poneros un ejemplo real imaginad que queremos controlar que nuestra aplicación solo pueda ser llamada de manera segura sobre SSL, para ellos podríamos crear un message handler:

public class SslMessageHandler : DelegatingHandler

{

    protected override Task<HttpResponseMessage> SendAsync(

        HttpRequestMessage request, 

        System.Threading.CancellationToken cancellationToken)

    {

        if (request.RequestUri.Scheme != Uri.UriSchemeHttps)

        {

            var forbiddenResponse =

                request.CreateResponse(HttpStatusCode.Forbidden);

 

            forbiddenResponse.ReasonPhrase = "SSL is required";

 

            return Task.FromResult(

                forbiddenResponse);

        }

 

        return base.SendAsync(request, cancellationToken);

    }

}

Y lo registramos:

config.MessageHandlers.Add(

        new SslMessageHandler());

Con esto comprobamos al principio del pipeline sí la petición se ejecuta de manera segura sobre https y sino creamos una respuesta de error al cliente. Si esto mismo lo hacemos con un filter estaríamos ejecutando todo el pipeline de Http Message handlers, creando el controlador, aplicando el filtro… esto al final acaba afectando al performance de nuestra api ya que todo ese tiempo de pipeline lo podríamos haber ahorrado usando un message handler.

Los filtros por el contrario tienen otra finalidad, por ejemplo los filtros para excepciones se ejecutan solo sí dentro del pipeline del controlador se produce una excepción, además como sabéis los filtros tienen un orden de ejecución dependiendo de su tipo, los primeros en ejecutarse son los AuthorizationFilters, luego los ActionFilters y por último los ExceptionFilters y ademas estos filtros los podemos aplicar globalmente, por controlador o por acción.

Un saludo.

Bibliografía: PRO ASP.NET WebAPI

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *