// the find
ardalis/ApiEndpoints
A project for supporting API Endpoints in ASP.NET Core web applications.
ApiEndpoints is a thin wrapper over ASP.NET Core MVC that enforces one-class-per-endpoint through a fluent generic base class hierarchy. It's for teams who like the organization of feature folders but don't want to pull in MediatR just to break up fat controllers. The author himself now recommends FastEndpoints instead.
The Roslyn analyzer that fires when you add a second public method to an endpoint class is genuinely useful — it enforces the single-responsibility constraint at compile time rather than relying on developer discipline. The fluent generic chain (`EndpointBaseAsync.WithRequest<T>.WithActionResult<U>`) makes the contract of each endpoint visible in the class declaration without opening the file. The Swashbuckle and NSwag companion packages mean Swagger grouping still works without manual `[ApiExplorerSettings]` hacks. Functional tests in the sample app test real HTTP behavior via `WebApplicationFactory`, not mocked controllers.
This is a solved problem: the library's own README recommends you use FastEndpoints or Minimal APIs instead, and that recommendation is correct. It still requires `AddControllers()` and `MapControllers()`, so you're dragging in the full MVC pipeline — all the filters, model binding overhead, and action descriptor machinery — for what is essentially a naming convention. The breaking changes between v3 and v4 (renaming `WithResponse` to `WithResult`/`WithActionResult`) are the kind of churn you'd expect from a library that's fighting the framework rather than working with it. No built-in validation pipeline, no result types — you still wire up FluentValidation or `ModelState` manually, same as controllers.