Controllers vs Minimal APIs

// Controller-based
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase {
    [HttpGet("{id}")]
    public IActionResult Get(int id) => Ok(_service.GetById(id));
}

// Minimal API equivalent
app.MapGet("/api/products/{id}", (int id, IProductService service) => service.GetById(id));

Common follow-ups: What performance difference exists between the two approaches?;Can you mix both controllers and minimal APIs in the same project?

// Controllers: automatic model validation via [ApiController]
[ApiController]
public class ProductsController : ControllerBase {
    [HttpPost]
    public IActionResult Create(ProductDto dto) {
        // ModelState.IsValid already checked automatically, 400 returned if invalid
        return Ok(_service.Create(dto));
    }
}

// Minimal API: validation typically requires explicit logic or a library like FluentValidation

Common follow-ups: How does IEndpointFilter provide similar functionality to MVC's filter pipeline?;What third-party libraries fill the validation gap for minimal APIs?

// Minimal APIs: more direct execution path
app.MapGet("/ping", () => "pong");  // minimal framework overhead

// Controllers: more machinery invoked (filters, model binding, action selection)
[HttpGet("ping")]
public IActionResult Ping() => Ok("pong");

Common follow-ups: At what request complexity does the framework overhead difference become negligible?;What specific MVC pipeline stages does a minimal API bypass?

// ProductEndpoints.cs
public static class ProductEndpoints {
    public static void MapProductEndpoints(this WebApplication app) {
        var group = app.MapGroup("/api/products").RequireAuthorization();
        group.MapGet("/", GetAll);
        group.MapGet("/{id}", GetById);
        group.MapPost("/", Create);
    }
}

// Program.cs
app.MapProductEndpoints();

Common follow-ups: How does MapGroup let you apply shared authorization or filters to an entire group at once?;What naming/organizational conventions work best for large minimal API codebases?

// Decision framework applied:
// - Public-facing, complex e-commerce API with dozens of related resources, filters, views -> Controllers
// - Internal, narrow, high-throughput pricing microservice with 5 endpoints -> Minimal APIs
// - Team deeply experienced with MVC, tight deadline -> Controllers (familiarity wins)

Common follow-ups: What signals suggest a minimal API project has grown complex enough to benefit from migrating to controllers?;How do teams that use both approaches keep conventions consistent across services?

// Minimal API: automatic inference based on parameter characteristics
app.MapPost("/products/{id}", (int id, ProductDto dto, [FromServices] IProductService service) => {
    // id inferred from route, dto inferred from body, service explicitly from DI
    return service.Update(id, dto);
});

Common follow-ups: When does minimal API's automatic inference get it wrong, requiring explicit attributes?;How does model binding performance compare between the two approaches?

public class ValidationFilter<T> : IEndpointFilter {
    public async ValueTask<object?> InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next) {
        var dto = context.GetArgument<T>(0);
        var validationResults = new List<ValidationResult>();
        if (!Validator.TryValidateObject(dto, new ValidationContext(dto), validationResults, true))
            return Results.ValidationProblem(validationResults.ToDictionary(...));
        return await next(context);
    }
}

app.MapPost("/products", Create).AddEndpointFilter<ValidationFilter<ProductDto>>();

Common follow-ups: How does this compare in complexity/maintainability to just using controllers with [ApiController]?;What other MVC conveniences commonly need to be reimplemented for minimal APIs?

var app = builder.Build();

app.MapControllers();  // existing, complex business logic endpoints

app.MapGet("/health", () => Results.Ok("healthy"));  // simple, high-frequency endpoint as minimal API
app.MapGet("/version", () => Results.Ok(new { version = "1.4.2" }));

Common follow-ups: What routing conflicts can arise when mixing both approaches in the same URL space?;Is this hybrid approach considered a maintainability risk long-term?

// Controller: all actions share the same constructor-injected dependencies
public class ProductsController(IProductService service, ILogger<ProductsController> logger) : ControllerBase {
    [HttpGet] public IActionResult GetAll() => Ok(service.GetAll());  // has logger even if unused here
}

// Minimal API: each endpoint declares only what it actually needs
app.MapGet("/products", (IProductService service) => service.GetAll());  // no unused logger dependency
app.MapPost("/products", (IProductService service, ILogger<Program> logger, ProductDto dto) => { ... });

Common follow-ups: Does this parameter-based injection have any measurable performance difference from constructor injection?;How does this affect testability compared to controller-based DI?

builder.Services.AddAuthorization(options => options.AddPolicy("AdminOnly", p => p.RequireRole("Admin")));

// Controller usage
[Authorize(Policy = "AdminOnly")]
public class AdminController : ControllerBase { }

// Minimal API usage of the SAME policy
app.MapDelete("/admin/users/{id}", DeleteUser).RequireAuthorization("AdminOnly");

Common follow-ups: Are there any policies that behave subtly differently between the two invocation styles?;How would you audit a hybrid codebase to ensure policy consistency across both styles?