Por anos, o padrão MVC Controller foi o rei incontestável do ASP.NET. Quando as Minimal APIs chegaram no .NET 6, muitos as descartaram como um “brinquedo” para pequenos microsserviços ou projetos de hobby.

No entanto, à medida que o ecossistema amadureceu com o .NET 8 e o .NET 9 e 10, a escolha entre eles não é apenas sobre tamanho de arquivo ou “açúcar sintático” — trata-se de filosofia arquitetural, sobrecarga de memória e da forma como o framework subjacente lida com o seu código.

1. A ‘mágica’ nos bastidores

A maior diferença que ninguém menciona é como o framework descobre e invoca seus endpoints.

Controllers: Pipeline MVC Completo

Controllers utilizam toda a infraestrutura do MVC, incluindo:
Action Invoker
  Model Binding
  Filters
  Validation Pipeline
  Formatters
  Metadata Providers
  ApiController conventions

Durante a inicialização da aplicação, o framework descobre Controllers e Actions através de metadados e reflection otimizada. Porém, o ASP.NET Core moderno utiliza diversos mecanismos de cache e otimização interna para reduzir esse custo.

O resultado é um pipeline extremamente poderoso e flexível, mas naturalmente mais complexo.

Minimal APIs: Pipeline Mais Enxuto

Minimal APIs utilizam um modelo mais direto. Os handlers são registrados como delegates e passam por um pipeline menor que o MVC tradicional.

Isso reduz:
quantidade de abstrações
alocações de memória
complexidade do pipeline
tempo de startup em alguns cenários

Mas é importante entender que Minimal APIs não “pulam” toda a infraestrutura do ASP.NET Core. Elas ainda utilizam:
Endpoint Routing
Middleware Pipeline
Model Binding
Dependency Injection
Metadata para OpenAPI

A diferença é que o pipeline é mais leve e explícito.

A Diferença Mais Importante: Organização Arquitetural

A principal mudança trazida pelas Minimal APIs não é performance. É arquitetura.

Os Controllers Favorecem Estrutura em Camadas

Com Controllers, é comum organizar a aplicação por tipo:

Controllers/
Services/
Repositories/
DTOs/

Isso funciona muito bem em aplicações corporativas tradicionais, especialmente em equipes acostumadas com MVC.

Porém, com o tempo, muitos projetos acabam criando Controllers grandes demais:

UserController.cs
– Create
– Update
– Delete
– Login
– ResetPassword
– UploadPhoto
– ChangeRole

Esse problema é conhecido como “Fat Controller”.

As Minimal APIs Favorecem Vertical Slice Architecture

As Minimal APIs facilitam a organização por funcionalidade:

Features/
└── Users/
├── CreateUser/
├── DeleteUser/
└── UpdateUser/

Essa abordagem combina muito bem com:
CQRS
MediatR
aplicações modulares
microsserviços

 O Mito da Performance

As Minimal APIs normalmente possuem melhor throughput(vazão) e menor overhead que Controllers.

Isso é real, mas a diferença costuma ser relevante principalmente em cenários como:
microsserviços de alta escala
serverless
aplicações cloud-native
APIs extremamente simples
ambientes com cold start crítico

Em aplicações corporativas tradicionais, o custo dominante normalmente está em:
banco de dados
serialização JSON
chamadas externas
rede
autenticação

Nesses casos, a diferença entre Controllers e Minimal APIs tende a ser pequena. Ou seja:

O desempenho sozinho raramente deve ser o único critério arquitetural.

Quando Minimal APIs Também viram Problema

Um erro comum é tratar Minimal APIs como “tudo no Program.cs”.

Isso funciona em demos pequenas, mas rapidamente se torna inviável em aplicações reais.

Este código:

app.MapGet("/users", ...);
app.MapPost("/users", ...);
app.MapPut("/users/{id}", ...);

pode virar um enorme bloco difícil de manter.

A abordagem mais profissional é modularizar os endpoints:

public static class UserEndpoints
{
    public static void MapUserEndpoints(this IEndpointRouteBuilder app)
    {
        var group = app.MapGroup("/users");
        group.MapGet("/", GetUsers);
        group.MapPost("/", CreateUser);
    }
}

Além disso, o ASP.NET Core moderno oferece:
  Endpoint Filters
  Route Groups
  Typed Results
  OpenAPI integrado
  validação
  versionamento

Isso permite estruturar Minimal APIs de forma muito organizada.

Quando Controllers Ainda São Excelentes

Controllers continuam extremamente relevantes no .NET 8/9. Eles ainda são uma ótima escolha quando você precisa de:
convenções MVC maduras
  filtros globais
  APIs corporativas complexas
  versionamento avançado
  integração tradicional com Swagger/OpenAPI
  comportamento automático com ModelState
  equipes já acostumadas com MVC

A Microsoft continua dando suporte completo ao modelo baseado em Controllers. Eles não estão obsoletos.

Quando Minimal APIs Fazem Mais Sentido

Minimal APIs brilham especialmente em:
microsserviços
  aplicações cloud-native
  APIs menores e modulares
  serverless
  arquiteturas Vertical Slice
  aplicações com foco em simplicidade e explicitude

Além disso, muitos dos investimentos recentes do ASP.NET Core estão melhorando bastante a experiência com Minimal APIs no .NET 8/9.

Consideração Final

A discussão entre Controllers e Minimal APIs não deveria ser tratada como uma “guerra”.

A ASP.NET Core foi projetada justamente para permitir a convivência entre os dois modelos. Você pode:
manter Controllers em partes mais complexas do sistema
usar Minimal APIs em novos módulos
combinar ambos na mesma aplicação

No fim, a melhor escolha depende:
da arquitetura da aplicação
da experiência da equipe
do nível de complexidade
dos requisitos de performance
da estratégia de manutenção do projeto

Os Controllers continuam modernos e extremamente úteis.

As Minimal APIs também são uma excelente evolução da plataforma.

O importante não é seguir tendência, mas escolher conscientemente a abordagem mais adequada para o problema que você está resolvendo.