Why I Ditched Controllers for Minimal APIs (And You Should Too)

When Microsoft introduced Minimal APIs in .NET 6, my immediate reaction was, "Great, they are just copying Express.js to appeal to Node developers."

I was perfectly happy with my MVC Controllers. I liked my [ApiController] attributes, my routing attributes, and my heavily structured folders. I dismissed Minimal APIs as a toy for tiny microservices.

Fast forward to today, and I haven’t written a traditional Controller in over a year. I use Minimal APIs for everything.

Here is why I completely changed my mind, and why you should consider ditching Controllers for your next project.

1. The Boilerplate is Gone

Look at a standard ASP.NET Core Controller. It is incredibly verbose.

// The old, bloated way
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductService _productService;

    public ProductsController(IProductService productService)
    {
        _productService = productService;
    }

    [HttpGet("{id}")]
    [ProducesResponseType(typeof(ProductDto), StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    public async Task<IActionResult> GetProduct(int id)
    {
        var product = await _productService.GetByIdAsync(id);
        if (product == null) return NotFound();
        return Ok(product);
    }
}

That is 21 lines of code for a single GET endpoint. You have class declarations, constructor injection, routing attributes, and IActionResult wrappers.

Here is the exact same logic written as a Minimal API in Program.cs:

// The new, clean way
app.MapGet("/api/products/{id}", async (int id, IProductService productService) => 
{
    var product = await productService.GetByIdAsync(id);
    return product is not null ? Results.Ok(product) : Results.NotFound();
});

5 lines of code. The dependencies (IProductService) are injected directly into the delegate signature. It is instantly readable.

2. Performance (The Real Reason)

Controllers are slow.

Not "slow" in a way a human notices, but slow in a high-throughput environment. When a request hits a Controller, ASP.NET Core has to:

1. Use Reflection to find the controller class.
2. Instantiate the controller (and resolve all its constructor dependencies).
3. Execute the method.
4. Dispose of the controller.

Minimal APIs bypass all of this. There is no class to instantiate. The route is directly bound to a delegate function. Because of this, Minimal APIs allocate significantly less memory per request and can handle roughly 20-30% more requests per second than traditional MVC Controllers.

3. "But my Program.cs will become 10,000 lines long!"

This is the number one argument against Minimal APIs. If you put all your endpoints in Program.cs, it becomes a nightmare to maintain.

But you don't have to put them in Program.cs. You can easily group them using Extension Methods.

I usually structure my Minimal APIs like this:

// In a separate file: ProductEndpoints.cs
public static class ProductEndpoints
{
    public static void MapProductEndpoints(this IEndpointRouteBuilder app)
    {
        var group = app.MapGroup("/api/products").WithTags("Products");

        group.MapGet("/{id}", GetProduct);
        group.MapPost("/", CreateProduct);
    }

    private static async Task<IResult> GetProduct(int id, IProductService svc)
    {
        // ... logic
    }
}

Then in Program.cs, you just call:

app.MapProductEndpoints();

You get all the structural organization of Controllers, but all the performance benefits of Minimal APIs.

The Verdict

If you are building an API that returns HTML (using Razor Pages or MVC views), stick to Controllers. But if you are building a standard JSON REST API, Minimal APIs are the clear winner. They are faster, they require less code, and they play beautifully with the new Native AOT compilation features in .NET 8.