Les Minimal APIs d'ASP.NET Core éliminent la cérémonie des contrôleurs MVC traditionnels, offrant une approche rationalisée pour construire des endpoints HTTP avec significativement moins de code standard. Introduites dans .NET 6 et perfectionnées à travers .NET 8, 9 et maintenant .NET 10, les Minimal APIs sont devenues un choix prêt pour la production pour les microservices, les fonctions serverless et les services web légers.

Minimal APIs vs Contrôleurs

Les Minimal APIs utilisent des gestionnaires de routes de niveau supérieur définis directement dans Program.cs, tandis que les contrôleurs MVC nécessitent des définitions de classes, des attributs et un routage basé sur les conventions. Pour des opérations CRUD simples ou des microservices avec moins de 20 endpoints, les Minimal APIs réduisent généralement le code de 40 à 60%.

Architecture des Minimal APIs et Pipeline de Requêtes

Le pipeline de requêtes ASP.NET Core traite les requêtes HTTP à travers des composants middleware avant d'atteindre les gestionnaires d'endpoints. Les Minimal APIs s'intègrent parfaitement à ce pipeline tout en offrant une syntaxe plus déclarative pour la définition des routes.

Program.cscsharp

var builder = WebApplication.CreateBuilder(args);

// Register services for dependency injection
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
builder.Services.AddScoped<IProductRepository, ProductRepository>();

var app = builder.Build();

// Middleware pipeline configuration
app.UseExceptionHandler("/error");
app.UseHttpsRedirection();
app.UseAuthorization();

// Minimal API endpoint definitions
app.MapGet("/products", async (IProductRepository repo) =>
    Results.Ok(await repo.GetAllAsync()));

app.MapGet("/products/{id:int}", async (int id, IProductRepository repo) =>
    await repo.GetByIdAsync(id) is Product product
        ? Results.Ok(product)
        : Results.NotFound());

app.Run();

Ce pattern centralise les définitions de routes tout en maintenant un accès complet au conteneur d'injection de dépendances. Le paramètre IProductRepository démontre l'injection sans constructeur directement dans les délégués gestionnaires.

Groupes de Routes et Organisation des Endpoints

À mesure que les applications grandissent, l'organisation des endpoints devient critique. Les groupes de routes, introduits dans .NET 7, fournissent un espacement de noms et une configuration partagée sans sacrifier l'approche minimaliste.

ProductEndpoints.cscsharp

public static class ProductEndpoints
{
    public static void MapProductEndpoints(this WebApplication app)
    {
        var group = app.MapGroup("/api/products")
            .WithTags("Products")
            .RequireAuthorization();

        group.MapGet("/", GetAllProducts);
        group.MapGet("/{id:int}", GetProductById);
        group.MapPost("/", CreateProduct)
            .Accepts<CreateProductRequest>("application/json")
            .Produces<Product>(StatusCodes.Status201Created);
        group.MapPut("/{id:int}", UpdateProduct);
        group.MapDelete("/{id:int}", DeleteProduct)
            .RequireAuthorization("AdminOnly");
    }

    private static async Task<IResult> GetAllProducts(
        IProductRepository repo,
        CancellationToken ct)
    {
        var products = await repo.GetAllAsync(ct);
        return Results.Ok(products);
    }

    private static async Task<IResult> GetProductById(
        int id,
        IProductRepository repo,
        CancellationToken ct)
    {
        var product = await repo.GetByIdAsync(id, ct);
        return product is not null
            ? Results.Ok(product)
            : Results.NotFound();
    }

    private static async Task<IResult> CreateProduct(
        CreateProductRequest request,
        IProductRepository repo,
        IValidator<CreateProductRequest> validator,
        CancellationToken ct)
    {
        var validation = await validator.ValidateAsync(request, ct);
        if (!validation.IsValid)
            return Results.ValidationProblem(validation.ToDictionary());

        var product = await repo.CreateAsync(request.ToProduct(), ct);
        return Results.Created($"/api/products/{product.Id}", product);
    }
}

L'appel à app.MapProductEndpoints() dans Program.cs enregistre toutes les routes produit avec des exigences d'autorisation partagées et des métadonnées OpenAPI. Cette structure évolue bien pour des applications avec des centaines d'endpoints.

Liaison de Paramètres et Validation

Les Minimal APIs supportent plusieurs sources de liaison : paramètres de route, chaînes de requête, en-têtes, corps de requête et services du DI. Comprendre la priorité de liaison prévient les pièges courants en entretien.

Program.cs - Parameter binding examplescsharp

app.MapGet("/search", (
    [FromQuery] string? query,           // Explicit query string
    [FromQuery] int page = 1,            // Default value
    [FromQuery] int pageSize = 20,       // Default value
    [FromHeader(Name = "X-Correlation-Id")] string? correlationId,
    ILogger<Program> logger) =>
{
    logger.LogInformation("Search request: {Query}, Page: {Page}, CorrelationId: {CorrelationId}",
        query, page, correlationId);

    return Results.Ok(new { query, page, pageSize, correlationId });
});

// Complex model binding with validation
app.MapPost("/orders", async (
    [FromBody] CreateOrderRequest request,
    [FromServices] IValidator<CreateOrderRequest> validator,
    [FromServices] IOrderService orderService,
    HttpContext context,
    CancellationToken ct) =>
{
    var validationResult = await validator.ValidateAsync(request, ct);

    if (!validationResult.IsValid)
    {
        return Results.ValidationProblem(
            validationResult.Errors
                .GroupBy(e => e.PropertyName)
                .ToDictionary(
                    g => g.Key,
                    g => g.Select(e => e.ErrorMessage).ToArray()));
    }

    var userId = context.User.FindFirstValue(ClaimTypes.NameIdentifier);
    var order = await orderService.CreateOrderAsync(request, userId!, ct);

    return Results.Created($"/orders/{order.Id}", order);
});

L'attribut [FromBody] est optionnel pour les types complexes mais améliore la lisibilité. FluentValidation s'intègre naturellement via l'injection de dépendances, gardant la logique de validation séparée des gestionnaires d'endpoints.

Priorité des Sources de Liaison

Quand aucun attribut n'est spécifié, les Minimal APIs infèrent les sources de liaison : d'abord les paramètres de route, puis les chaînes de requête pour les types simples, et le corps de la requête pour les types complexes. Les attributs explicites comme [FromQuery] ou [FromBody] remplacent ce comportement.

Optimisation des Performances avec Native AOT

.NET 8 a introduit le support de la compilation Native AOT (Ahead-of-Time) pour les Minimal APIs, produisant des exécutables autonomes avec des temps de démarrage inférieurs à la milliseconde. Cette capacité rend les Minimal APIs idéales pour les déploiements serverless où la latence de démarrage à froid compte.

Program.cs - AOT-compatible configurationcsharp

var builder = WebApplication.CreateSlimBuilder(args);

// AOT-friendly JSON serialization
builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.TypeInfoResolverChain.Insert(0, AppJsonContext.Default);
});

var app = builder.Build();

app.MapGet("/health", () => Results.Ok(new HealthResponse("Healthy", DateTime.UtcNow)));

app.Run();

// Source-generated JSON serializer context
[JsonSerializable(typeof(HealthResponse))]
[JsonSerializable(typeof(Product))]
[JsonSerializable(typeof(List<Product>))]
internal partial class AppJsonContext : JsonSerializerContext { }

public record HealthResponse(string Status, DateTime CheckedAt);

La méthode CreateSlimBuilder exclut les fonctionnalités de framework inutiles, tandis que le JsonSerializerContext généré par source élimine la réflexion à l'exécution pour la sérialisation JSON. Les binaires AOT publiés pour des APIs simples mesurent typiquement 10-15 Mo comparés aux 80+ Mo pour les déploiements autonomes standards.

Typed Results et Métadonnées de Réponse

.NET 7 a introduit TypedResults pour la vérification au moment de la compilation des types de réponse, améliorant la précision de la documentation OpenAPI et détectant les incompatibilités de types pendant le développement.

csharp

// Strongly-typed results with OpenAPI metadata
app.MapGet("/products/{id:int}", async Task<Results<Ok<Product>, NotFound, ProblemHttpResult>> (
    int id,
    IProductRepository repo,
    CancellationToken ct) =>
{
    try
    {
        var product = await repo.GetByIdAsync(id, ct);

        return product is not null
            ? TypedResults.Ok(product)
            : TypedResults.NotFound();
    }
    catch (Exception ex)
    {
        return TypedResults.Problem(
            detail: "An error occurred retrieving the product",
            statusCode: StatusCodes.Status500InternalServerError);
    }
})
.WithName("GetProductById")
.WithOpenApi(operation =>
{
    operation.Summary = "Retrieves a product by ID";
    operation.Description = "Returns the product details or 404 if not found";
    return operation;
});

Le type union Results<T1, T2, T3> déclare tous les types de réponse possibles, que les générateurs Swagger/OpenAPI utilisent pour produire une documentation précise. Ce pattern est particulièrement précieux lors de la préparation aux questions d'entretien ASP.NET Core sur la conception d'API.

Prêt à réussir tes entretiens .NET ?

Entraîne-toi avec nos simulateurs interactifs, fiches express et tests techniques.

Explorer .NET

Filtres d'Endpoint pour les Préoccupations Transversales

Les filtres d'endpoint fournissent une fonctionnalité similaire au middleware mais limitée à des endpoints ou groupes spécifiques, gérant des préoccupations telles que le logging, la mise en cache et la transformation des requêtes.

ValidationFilter.cscsharp

public class ValidationFilter<T> : IEndpointFilter where T : class
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext context,
        EndpointFilterDelegate next)
    {
        var validator = context.HttpContext
            .RequestServices
            .GetService<IValidator<T>>();

        if (validator is null)
            return await next(context);

        var argument = context.Arguments
            .OfType<T>()
            .FirstOrDefault();

        if (argument is null)
            return await next(context);

        var validationResult = await validator.ValidateAsync(argument);

        if (!validationResult.IsValid)
        {
            return Results.ValidationProblem(
                validationResult.Errors
                    .GroupBy(e => e.PropertyName)
                    .ToDictionary(
                        g => g.Key,
                        g => g.Select(e => e.ErrorMessage).ToArray()));
        }

        return await next(context);
    }
}

// Usage in Program.cs
app.MapPost("/products", CreateProduct)
    .AddEndpointFilter<ValidationFilter<CreateProductRequest>>();

// Global filter registration via route group
var api = app.MapGroup("/api")
    .AddEndpointFilter(async (context, next) =>
    {
        var logger = context.HttpContext
            .RequestServices
            .GetRequiredService<ILogger<Program>>();

        var stopwatch = Stopwatch.StartNew();
        var result = await next(context);
        stopwatch.Stop();

        logger.LogInformation(
            "Endpoint {Method} {Path} completed in {ElapsedMs}ms",
            context.HttpContext.Request.Method,
            context.HttpContext.Request.Path,
            stopwatch.ElapsedMilliseconds);

        return result;
    });

Les filtres s'exécutent dans l'ordre d'enregistrement, avec le filtre le plus interne le plus proche du gestionnaire d'endpoint. Cette architecture permet une séparation propre de la validation, du logging et de la logique d'autorisation.

Patterns d'Authentification et d'Autorisation

Les Minimal APIs supportent les mêmes mécanismes d'authentification et d'autorisation que les contrôleurs MVC, avec une syntaxe de configuration plus déclarative.

Program.cs - JWT authentication setupcsharp

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = builder.Configuration["Jwt:Issuer"],
            ValidAudience = builder.Configuration["Jwt:Audience"],
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"]!))
        };
    });

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("AdminOnly", policy =>
        policy.RequireRole("Admin"))
    .AddPolicy("PremiumUser", policy =>
        policy.RequireClaim("subscription", "premium", "enterprise"));

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

// Protected endpoints
app.MapGet("/admin/users", async (IUserService userService) =>
    Results.Ok(await userService.GetAllUsersAsync()))
    .RequireAuthorization("AdminOnly");

app.MapGet("/profile", async (ClaimsPrincipal user, IUserService userService) =>
{
    var userId = user.FindFirstValue(ClaimTypes.NameIdentifier);
    var profile = await userService.GetProfileAsync(userId!);
    return Results.Ok(profile);
})
.RequireAuthorization();

// Anonymous endpoint within protected group
var protectedGroup = app.MapGroup("/api/secure")
    .RequireAuthorization();

protectedGroup.MapGet("/public-info", () => Results.Ok("This is public"))
    .AllowAnonymous();

La méthode d'extension RequireAuthorization accepte des noms de politiques ou peut être appelée sans arguments pour exiger tout utilisateur authentifié. Comprendre ces patterns est essentiel pour les questions d'entretien sur l'authentification et l'autorisation.

Questions d'Entretien : Patterns Courants

Les entretiens techniques explorent fréquemment les différences entre les Minimal APIs et les contrôleurs traditionnels. Le tableau ci-dessous résume les distinctions clés :

| Aspect | Minimal APIs | Contrôleurs MVC | |--------|--------------|------------------| | Code standard | Faible - délégués gestionnaires directs | Plus élevé - classe + méthode + attributs | | Routage | En ligne avec MapGet, MapPost | Basé sur attributs ou conventions | | Liaison de modèle | Automatique avec attributs optionnels | Convention + attributs | | Filtres | Filtres d'endpoint | Filtres d'action + middleware | | Support AOT | Complet depuis .NET 8 | Limité, lourd en réflexion | | Testabilité | Basée sur fonctions, facile à tester unitairement | Nécessite instanciation du contrôleur | | Idéal pour | Microservices, APIs simples | Grandes applications, workflows complexes |

Conseil d'Entretien

Quand on demande "Quand choisiriez-vous les contrôleurs plutôt que les Minimal APIs ?", mentionnez les applications complexes nécessitant des filtres d'action, une personnalisation de la liaison de modèle, ou des bases de code existantes avec des patterns MVC établis. Les Minimal APIs excellent pour les microservices greenfield et les fonctions serverless.

Tests des Endpoints Minimal API

Les tests d'intégration avec WebApplicationFactory fournissent une vérification réaliste des endpoints sans déployer l'application.

ProductEndpointsTests.cscsharp

public class ProductEndpointsTests : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient _client;
    private readonly WebApplicationFactory<Program> _factory;

    public ProductEndpointsTests(WebApplicationFactory<Program> factory)
    {
        _factory = factory.WithWebHostBuilder(builder =>
        {
            builder.ConfigureServices(services =>
            {
                // Replace real repository with mock
                services.RemoveAll<IProductRepository>();
                services.AddScoped<IProductRepository, MockProductRepository>();
            });
        });
        _client = _factory.CreateClient();
    }

    [Fact]
    public async Task GetProducts_ReturnsOkWithProductList()
    {
        // Act
        var response = await _client.GetAsync("/api/products");

        // Assert
        response.StatusCode.Should().Be(HttpStatusCode.OK);

        var products = await response.Content
            .ReadFromJsonAsync<List<Product>>();

        products.Should().NotBeNull();
        products.Should().HaveCountGreaterThan(0);
    }

    [Fact]
    public async Task GetProductById_WithInvalidId_ReturnsNotFound()
    {
        // Act
        var response = await _client.GetAsync("/api/products/99999");

        // Assert
        response.StatusCode.Should().Be(HttpStatusCode.NotFound);
    }

    [Fact]
    public async Task CreateProduct_WithValidRequest_ReturnsCreated()
    {
        // Arrange
        var request = new CreateProductRequest("Test Product", 29.99m, "Test Description");

        // Act
        var response = await _client.PostAsJsonAsync("/api/products", request);

        // Assert
        response.StatusCode.Should().Be(HttpStatusCode.Created);
        response.Headers.Location.Should().NotBeNull();
    }
}

Pour une exploration plus approfondie des patterns d'architecture propre dans les applications .NET, la couche service doit être testée indépendamment avec des tests unitaires, tandis que les tests d'intégration vérifient le pipeline de requêtes complet.

Conclusion

Les Minimal APIs représentent l'approche moderne pour construire des services HTTP dans ASP.NET Core :

Les groupes de routes et l'organisation des endpoints évoluent des microservices simples aux applications complexes
Les filtres d'endpoint fournissent une séparation propre des préoccupations transversales comme la validation et le logging
TypedResults permet la vérification au moment de la compilation des types de réponse et une documentation OpenAPI précise
La compilation Native AOT offre des temps de démarrage inférieurs à la milliseconde pour les déploiements serverless
Les tests d'intégration avec WebApplicationFactory assurent une vérification réaliste des endpoints

Pour la préparation aux entretiens, concentrez-vous sur l'articulation des cas où les Minimal APIs sont appropriées versus les contrôleurs traditionnels, et démontrez une compréhension du pipeline de requêtes, de l'injection de dépendances et des patterns d'authentification.

Passe à la pratique !

Teste tes connaissances avec nos simulateurs d'entretien et tests techniques.

Créer mon compte gratuit

ASP.NET Core Minimal APIs en 2026 : Architecture, Performance et Questions d'Entretien