Los middlewares en ASP.NET Core son el mecanismo que procesa cada request en tu API desde que entra hasta que se devuelve la respuesta. Aquí aprendes cómo funciona el pipeline, por qué importa el orden y cómo crear un middleware personalizado paso a paso, ideal si trabajas con .NET o te preparas para una entrevista técnica.
Qué son los middlewares y cómo procesan un request
Cada middleware ejecuta un pedacito de lógica: una validación, una transformación de datos o una consulta al servidor. Luego pasa el control al siguiente middleware y así sucesivamente, formando una secuencia. Cuando el último termina su trabajo, la respuesta empieza a devolverse en sentido inverso hasta llegar al cliente.
Esa respuesta no siempre es positiva. Puede ser un error, pero igual debe atravesar todos los middlewares para que cada uno aplique su validación según el escenario.
¿Qué es un middleware en ASP.NET Core? Es un componente que intercepta el request y la respuesta dentro del pipeline de la aplicación, ejecuta lógica específica y delega al siguiente middleware en la cadena.
Por qué el orden del pipeline importa tanto
La documentación oficial de Microsoft llama pipeline o tubería a esta secuencia [01:36]. El orden no es decorativo: define cómo se aplican aspectos como CORS, autenticación, autorización, los custom middlewares y, al final, el middleware de endpoints que devuelve los datos.
Dentro del archivo Program.cs, toda la sección de configuración de middlewares debe respetar ese orden para que los requests se procesen correctamente. Los middlewares personalizados van justo entre MapControllers y la parte de autorización [03:18]. No es obligatorio, pero es la recomendación oficial para no romper la secuencia.
Cuál es la posición correcta de un custom middleware
La zona segura para insertar lógica propia está antes del endpoint mapping y después de la autorización. Si lo colocas fuera de ahí, puedes afectar validaciones críticas como CORS o autenticación.
Cómo crear un middleware personalizado en .NET
Un middleware en línea, dentro de Program.cs, usa el método genérico Use con dos parámetros clave:
context: contiene el request, el path, los encabezados, las cookies y todo lo que envía el cliente.next: avisa al siguiente middleware que ya puede ejecutarse.
Después del await next.Invoke(), puedes leer la respuesta procesada con context.Response.StatusCode y registrarla. En el ejemplo de la clase, un simple Console.WriteLine imprime el path entrante y el status code saliente.
Al ejecutar una llamada a api/WeatherForecast, la consola muestra el path del request y la respuesta 200. Si llamas api/WeatherForecast/4 con un ID válido, también responde 200. Pero si envías un ID inválido como 50, el middleware captura un bad request y lo imprime [06:55]. Eso confirma que intercepta tanto los casos exitosos como los errores.
¿Para qué sirve el método InvokeAsync en un middleware? Es el punto de entrada que ejecuta la lógica del middleware y llama al siguiente con await next(context). Todos los middlewares lo implementan con esa firma.
Cómo extraer un middleware a su propia clase
Escribir middlewares directamente en Program.cs funciona para un demo, pero no para un proyecto real. La práctica recomendada es crear una carpeta Middlewares y dentro una clase como RequestLoggingMiddleware.cs [07:50].
La estructura mínima de esa clase incluye:
- Un constructor que recibe un
RequestDelegate (el next) como parámetro.
- Un método
InvokeAsync(HttpContext context) con la lógica antes y después del await next(context).
- Una clase de extensión opcional, por ejemplo
RequestLoggingMiddlewareExtensions, que expone un método UseRequestLogging().
Con esa extensión, el registro en Program.cs queda tan limpio como app.UseCors(), app.UseHttpsRedirection() o app.UseAuthorization(). Solo añades app.UseRequestLogging() y la lógica vive aislada en su propio archivo.
Qué incluir dentro de InvokeAsync
El context te da acceso completo al request entrante: encabezados, cookies, path y parámetros. Después del next, puedes inspeccionar la respuesta. Esa ventana antes y después es donde caben tareas como logging, métricas, manejo de excepciones o enriquecimiento de encabezados.
Retos para practicar middlewares en ASP.NET Core
Dos ejercicios para afianzar el concepto:
- Mueve
UseCors después de MapControllers y consume la API desde un cliente HTML o React. Observa si CORS sigue funcionando. Esto demuestra por qué el orden importa.
- Modifica el
RequestLoggingMiddleware para que, en lugar de imprimir solo el path y el status, use un Stopwatch y mida el tiempo total que tarda el request de inicio a fin.
Los middlewares te abren la puerta a logging estructurado, métricas de rendimiento, autenticación personalizada y manejo centralizado de excepciones. Cuéntame en los comentarios qué middleware vas a construir primero en tu proyecto.
