Come abbiamo introdotto nel nostro articolo su ASP.NET Core 7 (https://www.aspitalia.com/articoli/aspnet-core7/novita-aspnetcore-blazor-net7-p-4.aspx) in Minimal API possiamo raggruppare endpoint tramite route group:

app.MapGroup("/public/user")
    .MapUsersApi()
    .WithTags("Public");

app.MapGroup("/private/user")
    .MapUsersApi()
    .WithTags("Private")
    .RequireAuthorization();

public static RouteGroupBuilder MapUsersApi(this RouteGroupBuilder group)
{
    group.MapGet("/", GetAllUsers);
    group.MapGet("/{id}", GetUser);
    group.MapPost("/", CreateUser);
    group.MapPut("/{id}", UpdateUser);
    group.MapDelete("/{id}", DeleteUser);

    return group;
}

Questa tecnica presenta un gran numero di vantaggi, tra cui

• la possibilità di riutilizzare gli stessi endpoint in diversi contesti (per esempio private e public, nell'esempio in alto);
• la possibilità di definire dei prefissi di routing al di fuori dei veri e propri endpoint, così che si possano semplificare eventuali refactoring o aggiornamenti;
• poter associare configurazioni a interi gruppi, che verranno poi ereditate dai veri e propri endpoint, un po' come accade con i filtri a livello di controller (per esempio nel codice in alto abbiamo impostato come protetti tutti gli endpoint del gruppo private).

Ovviamente questi concetti si applicano anche alla output cache:

app.MapGroup("/public/user")
    .MapUsersApi()
    .CacheOutput(); // <-- eventuali policy o configurazioni qui

Nell'esempio in alto, abbiamo attivato l'output cache su tutti gli endpoint mappati sul gruppo /public/user. Ovviamente, nonostante questo gruppo supporti metodi di POST, PUT e DELETE, in assenza di custom policy, solo quelli in GET saranno oggetto di caching.