framework VS ApiEndpoints

Feather HTTP would be a good place to start if you wanted to understand what this means for implementations.

So, when I saw in late December that Fowler had created a new project called FeatherHttp I was stoked. It appeared to me that this project was a manifestation of his thoughts around .NET bloat. I jumped on it and quickly started buzzing around the threads. I wanted to help write the documentation. I wanted to be a part of this effort. Also, here was a .NET open source project in the initial stages. I felt I could contribute. I was also very excited to work with David Fowler.

I personally prefer the API Endponts project that doesn’t get the love it deserves. It’s really the best of both worlds. It breaks each endpoint up into one file to make it easier to manage and prevents ginormous Controllers.

I personally think it feels "cleaner" when using the controllers instead because they provide more out of the box features. Having one endpoint per file is a nice thing so I'm thinking about using the ApiEndpoints ( https://github.com/ardalis/ApiEndpoints ) package.

You can follow a "controller per endpoint" strategy. One good way to do it is with Steve Smith ApiEndpoints: https://github.com/ardalis/ApiEndpoints

I'm not disputing the benefits of thin controllers but there are other ways to make the controllers thinner. For example, I could use libraries such as ApiEndpoints which allows me to have one handler class per REST endpoint. Basically, MediatR pattern but at the ASP.net level.

The only think I would suggest is to break endpoints into separate files via smth like this https://github.com/ardalis/ApiEndpoints

You really should compare against https://github.com/ardalis/ApiEndpoints