Minimal APIs en .NET y C#: Microservicios Ligeros y Ultra Rápidos
Lo Que Dominarás en Este Tutorial
- Configure a streamlined web application using WebApplication.CreateBuilder().
- Implement endpoint filters for cross-cutting authentication and validation.
- Leverage TypedResults<T> for compile-time verified HTTP responses.
1. Building the Endpoint Pipeline
Minimal APIs discard traditional controller boilerplate, enabling concise route definition with direct lambda mapping and automatic model binding.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
var app = builder.Build();
app.MapGet("/api/health", () => TypedResults.Ok(new { Status = "Healthy", Timestamp = DateTime.UtcNow }));
app.MapPost("/api/items", (CreateItemRequest request, IItemRepository repo) => {
var created = repo.Add(request);
return TypedResults.Created($"/api/items/{created.Id}", created);
});
app.Run();
Evaluación Rápida: Pon a Prueba tus Conocimientos
Preguntas Frecuentes
Profundizando: las Minimal APIs en la práctica
En la primera demo, los endpoints viven dentro de Program.cs, pero un servicio en producción necesita estructura alrededor. Los equipos que escalan bien con Minimal APIs tratan los controladores de ruta como una cáscara fina: las rutas se agrupan por funcionalidad, los filtros de endpoint centralizan la autenticación y la validación transversales, TypedResults mantiene cada contrato de respuesta verificado en tiempo de compilación, y los repositorios y contextos de EF Core llegan por la misma inyección de dependencias que usarías en MVC. El framework elimina el código repetitivo de los controladores, no la arquitectura; y como el arranque es rápido y la huella de memoria pequeña, una Minimal API bien organizada crece de prototipo de un solo archivo a microservicio de alto rendimiento sin reescribirse. Esa continuidad es la verdadera ganancia del patrón: el código del día uno puede seguir siendo el código del día cien, si la organización de rutas, filtros y servicios acompaña al tráfico.
Errores comunes
- Convertir Program.cs en un cajón de sastre. Cientos de controladores en línea en un solo archivo se vuelven imposibles de probar en un mes. Agrupa las rutas por área funcional y mueve la lógica de negocio a servicios inyectados, dejando los controladores como adaptadores de una línea.
- Devolver tipos anónimos desde cada endpoint. Las respuestas anónimas debilitan tu documentación OpenAPI y tus pruebas unitarias. Prefiere TypedResults<T> para que el compilador verifique las respuestas de éxito y de error, como demuestran los endpoints de salud y de elementos del tutorial.
- Repetir la validación dentro de cada controlador. Las comprobaciones de autenticación y de entrada copiadas y pegadas se desincronizan con el tiempo. Los filtros de endpoint existen precisamente para ejecutar esa lógica transversal en un solo lugar, antes de que corra el controlador.
- Confundir el enlace de modelos con la validación. El binding automático solo da forma a los datos entrantes según tu tipo de petición; no demuestra que los valores sean sensatos. Las cargas malformadas o maliciosas siguen necesitando validación explícita antes de llegar a un repositorio.
Preguntas frecuentes
¿Cuándo conviene seguir con controladores MVC en vez de Minimal APIs?
Para APIs muy grandes organizadas en torno a convenciones por controlador, o equipos ya estandarizados en patrones MVC, los controladores siguen siendo una opción razonable. Las Minimal APIs ganan donde importan sus fortalezas documentadas: menos sobrecarga de reflexión, arranque más rápido y menor huella de memoria en servicios enfocados.
¿Las Minimal APIs admiten inyección de dependencias como MVC?
Sí, por completo. Los servicios, incluido un DbContext de EF Core, se inyectan directamente en los parámetros del controlador de ruta mediante el contenedor estándar. Afirmar que las Minimal APIs carecen de inyección de dependencias es simplemente falso: es una parte central del modelo.
¿Cómo organizo los endpoints cuando la API crece?
Divide los mapeos por área de recurso usando grupos de rutas y métodos de extensión por funcionalidad, de modo que Program.cs se lea como una raíz de composición: configuración del builder, registro de servicios y una llamada de mapeo por cada funcionalidad.