Controller based APIs are deprecated?

[ladeak]

Build sessions: https://youtu.be/l32fiBG9YeQ?t=1823 mentions that minimal APIs is the new recommendation for going forward new webapps.
That is a substantial change compared to previous communications, where it was always said that both controller-based APIs and minimal APIs live side-by-side serving different purpose / style of applications.

1. Does it mean I should start thinking about migrating controller-based APIs to minimal APIs?
2. Is there going to be any official, 1start party support with tooling to this?
3. Could source generators generate minimal API registrations from existing controllers?

[gfoidl]

Controller based APIs will still be there in the future and you can use them.
No need to migrate your controllers to minimal APIs.

But minimal APIs is the area where future developments in ASP.NET Core will happen.

• they are lighter than controller based APIs
• can have source generators to create the "behind the scenes code"
• thus can use AOT
• new features like built-in validation, etc.

---

It's quite similar to MVC pages <-> Razor pages. Both exists, and provide a different way to achieve the goal.
None of them will get deprecated.

What may happen (my personal opinion) is that some area may get more attention than the other. But this doesn't mean that the other one will be removed or that like.

[ladeak]

So, if you have an app with 1500 endpoints and active development, do you start adding new endpoints with minimal apis, or you keep adding controller based endpoint? Would you strlart migrating controller apis on touch basis?

[gfoidl]

Personal opinion follows.

do you start adding new endpoints with minimal apis, or you keep adding controller based endpoint?

When it's a new featue, then I'd use minimal APIs.
Extending existing features, then I'd add it to the controller.

Would you strlart migrating controller apis on touch basis?

When it's easy to migrate, then I'd do it for smaller controllers. But w/ a distinct PR, so that the "touch basis" change doesn't get noise with the migration.

---

I don't know what your controller / actions are doing. When you have applied a pattern like CQRS or at least anything that offloads the work to specific handlers, then the migration should be quite easy, as it's basically just building the query / command and then forwarding it to some kind of (internal) bus + handling of the result which is different in minimal APIs (TypedResults and friends).

But I wouldn't change the 1.500 endpoints just to go from controller -> minimal APIs. I don't see any reason therefore.
For new endpoints see above.
When perf-testing shows that there are some really hot endpoints, then you can try minimal APIs on them and see if the perf-targets become closer and then maybe reason for a migration of this endpoint.

[ladeak]

I think. If the key investments happen for minimal apis it might worth slowly trainsitioning, but as you said I would jump on all of them.
It won't become easier later either.

(Unless some migration tool is given)

And I think the structure of controllers is quite nice to keep.