Content for Minimal APIs scaffolding with .NET 7 features

The team will be rolling out a number of features for .NET 7, some of which we want to include in our scaffolding to make the new functionalities more easily adopted.

Existing scaffolded items include:

• Minimal API with read/write endpoints
• Minimal API with read/write endpoints (with OpenAPI)
• Minimal API with endpoints, using Entity Framework
• Minimal API with endpoints, using Entity Framework (with OpenAPI)

List of our .NET 7 features:

• Route groups: allows devs to relate their endpoints by putting them into the same group which can be decorated with metadata
• Endpoint filters: allows users to implement parameter validation or custom response processing
• Results API improvements: easier testing and interacting
• Improved OpenAPI integration: support for endpoint metadata providers

Ideas for scaffolded items:

• Minimal API with a route group
• Minimal API with a route group (with OpenAPI)
• Minimal API with endpoints, using filters
• Minimal API with endpoints, using filters (with OpenAPI)
• Minimal API with endpoints, using Result API
• Minimal API with endpoints, using Result API (with OpenAPI)
• Minimal API with endpoints (with OpenAPI using an endpoint metadata provider)

• ideas from EF team, C# folks, etc.

From the previous minimal API issue:

When OpenAPI is opted-in to, the required packages and startup configuration code should be applied to the project.

For the items using Entity Framework, just like the existing Web API scaffolders, the user can select to have a DbContext created or select an existing DbContext. The appropriate packages and startup configuration code should be applied to project for Entity Framework based on the user’s selection.

In lieu of selecting a controller name, the user will select a class name that will contain the generated endpoint mapping code. If the class doesn’t exist, a new static class will be created and the extension method added to it. If the class already exists, it must be static, and the extension method will be added to it. The name of the class will default to [ModelClass]Endpoints, e.g. given model class Widget the class will be named WidgetEndpoints. The static method will be named Map[ModelClass]Endpoints, e.g. given model class Widget the method will be names MapWidgetEndpoints.

The application startup code should be updated by the scaffolder to call the generated extension method that maps the endpoints.

[DamianEdwards]

I think the speclet there was based on an earlier design of route groups. Whatever the scaffolding produces now is what we’d recommend you use as a starting point.

[captainsafia]

Does it make sense to make the return type for these a RouteGroupBuilder or IEndpointRouteBuilder so that users can continue to modify the output? It seems to align more cleanly to me with the other builder patterns we have.

public static void MapWidgetEndpoints(this IEndpointRouteBuilder routes)

WithOpenApi integration in these looks good. One thing to note is that it’ll depend on RC1 since we did some work to fix up route groups + WithOpenApi in RC1.