Provide an API experience that scales down well and is easier to learn

[glennc]

Title: Provide an API experience that scales down well and is easier to learn

ASP.NET Core does not provide a smooth way to scale an API down. We provide MVC which has lots of features, but also lots of concepts to learn. We want to provide experiences for building APIs that can start simpler, with a clearer getting started experience, and can smoothly progress to controllers if desired.

Our results from Feather studies and some of our Cloud Native user studies have shown that developers new to .NET react well to more simplified API experiences, and we think that also dovetails well with the Cloud Native theme as frequently the complexity that Controllers are designed to allow you to manage are instead managed across process/project boundaries.

This epic will allow us to enhance our API offering by extracting features currently only available in MVC, allowing them to be used outside of MVC. The intent is to allow these extracted features to be used in a functions/lambda model as well as a controller model of APIs. We started this work with Endpoint routing, but today that experience lacks a lot of desirable features, like model binding and validation, and doesn't have a clear story for better code organization once you grow beyond what fits well in an inline lambda.

Initial Principles/Goals:

1. Improve the endpoint routing APIs to the point that we could make it the default API story in ASP.NET Core
   1. Allow using features that are currently only available in MVC that make sense (model binding is the big one)
   2. Provide a smooth migration experience from inline lambda, to functions, to classes or controllers as code organization for an API
2. Don't create APIs for small apps. The idea is not to create a less capable API experience. Instead we want to allow simple things to be simple. Allowing seamless mixing of controllers and non-controllers, sharing of all the concepts and infrastructure that make sense.
3. Ensure APIs are good for our single-file/trimming/AOT experiences. Ensuring that a small API also produces a small binary output when built.
4. Improve the performance of MVC by getting middleware-like perf for extracted components and only paying of those components when you need them.

Sub-issues

1. New lightweight programming model for APIs (Simplify API-building experience without controllers #27347)
2. User learning arc for new minimal/focused ASP.NET Core API experience (User learning arc for new minimal/focused ASP.NET Core API experience #30580)

[StefanBertels]

Hopefully this simplification approach will make DI (dependency injection) at least optional and reduce "filter magic".
Meanwhile I built my own small WebApi host helper (wrapper library) that solves something like this -- I just have to create some MyController class, reference my helper lib and add a one-liner somewhere (e.g. Main) to start background kestrel to get a REST api using json.
Getting rid of boiler plate code was a challenge because default code relies heavily on DI and filters.