ASP.NET Core Minimal APIs vs Controllers in .NET 10

When you start a new web API in .NET 10, the first fork in the road is also one of the most consequential: Minimal APIs or controllers? Both are first-class, both are fully supported, and both can build serious production services. The choice is not about which is "better" in the abstract it is about which fits the shape of your project, your team, and how you expect the codebase to grow. This guide is a decision framework, not a winner declaration: how each model works, where each excels, and how to choose without regret.

The two models in brief

Controllers are the long-established MVC-style approach: endpoints are methods on classes that inherit from a base controller, grouped by convention, with attributes for routing and behaviour. Minimal APIs, introduced more recently and steadily matured, let you define endpoints directly as route handlers typically lambda or method references mapped to routes with far less ceremony and no required class hierarchy.

// Minimal API: the endpoint is the mapping.
app.MapGet("/products/{id:int}", async (int id, IProductService svc) =>
    await svc.Find(id) is { } p ? Results.Ok(p) : Results.NotFound());

// Controller: the endpoint is a method on a class.
[ApiController]
[Route("products")]
public class ProductsController(IProductService svc) : ControllerBase
{
    [HttpGet("{id:int}")]
    public async Task<IActionResult> Get(int id) =>
        await svc.Find(id) is { } p ? Ok(p) : NotFound();
}

Why the gap has narrowed

Early on, Minimal APIs were genuinely minimal fine for small services but missing pieces you needed at scale, which sent teams back to controllers. Release by release that gap has closed. Minimal APIs now handle the things that used to be controller-only: robust model binding, validation, grouping of related endpoints, filters for cross-cutting concerns, and clean OpenAPI generation. In .NET 10 they are a credible default for substantial APIs, not just toy ones.

Where Minimal APIs shine

Where controllers still earn their place

Keeping Minimal APIs from becoming a mess

The most common objection to Minimal APIs — "they do not scale to big apps" — is really an objection to undisciplined Minimal APIs. The fix is structure: do not dump every endpoint into one file. Group related endpoints into route groups, extract handlers into named methods or small classes, and register them through extension methods so your app startup stays readable.

// Organise endpoints by feature, registered via extension methods.
public static class ProductEndpoints
{
    public static IEndpointRouteBuilder MapProducts(this IEndpointRouteBuilder app)
    {
        var group = app.MapGroup("/products").WithTags("Products");
        group.MapGet("/{id:int}", GetProduct);
        group.MapPost("/", CreateProduct);
        return group;
    }
    // handlers as named methods, not anonymous lambdas, for testability
}

// Program.cs stays clean:
app.MapProducts();
app.MapOrders();

The decision framework

You can even mix them

ASP.NET Core lets controllers and Minimal APIs coexist in the same application, which is handy during a gradual migration or when one style fits part of your app better than another. Use this sparingly and deliberately, though a codebase split between two endpoint styles for no clear reason just makes onboarding harder. Pick a primary model and let the exceptions be genuine exceptions.