What are Minimal APIs, and how do they compare to controllers?
Quick Answer
Minimal APIs define HTTP endpoints as lambdas directly on the app — app.MapGet("/orders/{id}", (int id, IOrderService svc) => svc.Find(id)) — with no controller class. They're leaner and start faster; controllers give you more structure, built-in conventions, filters, and model-binding features for larger APIs.
Minimal APIs let me define endpoints as lambdas right on the WebApplication — app.MapGet, app.MapPost — with parameters bound by type from the route, query, body or DI. No controller class. They're a good fit for small services and microservices, and route groups plus endpoint filters cover grouping and cross-cutting concerns. Controllers still win when there are lots of endpoints, or I want the attribute-based conventions, action filters and the full [ApiController] behaviour. They share all the same plumbing, so I pick based on how much structure the API needs, not performance.
- Minimal APIs — great for small services, microservices, prototypes. Parameters are bound from route/query/body/DI by type. Group and share metadata with
app.MapGroup("/api/v1"). Endpoint filters (AddEndpointFilter) cover cross-cutting concerns. - Controllers — better when you have many endpoints, want attribute conventions, need action filters, complex model binding,
[ApiController]behaviours, or a team already organised around them. - Both use the same routing, DI, middleware and
IResult/ActionResult. You can mix them in one app. - Performance difference is small in real apps; choose on structure, not speed.