ASP.NET Core Minimal APIs eliminieren den Overhead traditioneller MVC-Controller und bieten einen schlanken Ansatz zur Erstellung von HTTP-Endpunkten mit deutlich weniger Boilerplate-Code. Seit der Einführung in .NET 6 und der kontinuierlichen Weiterentwicklung durch .NET 8, 9 und nun .NET 10 haben sich Minimal APIs zu einer produktionsreifen Wahl für Microservices, Serverless-Funktionen und leichtgewichtige Web-Services entwickelt.

Minimal APIs vs. Controller

Minimal APIs verwenden Top-Level-Route-Handler, die direkt in Program.cs definiert werden, während MVC-Controller Klassendefinitionen, Attribute und konventionsbasiertes Routing erfordern. Für einfache CRUD-Operationen oder Microservices mit weniger als 20 Endpunkten reduzieren Minimal APIs den Code typischerweise um 40-60%.

Architektur und Request-Pipeline von Minimal APIs

Die ASP.NET Core Request-Pipeline verarbeitet HTTP-Anfragen durch Middleware-Komponenten, bevor sie die Endpunkt-Handler erreichen. Minimal APIs integrieren sich nahtlos in diese Pipeline und bieten gleichzeitig eine deklarativere Syntax für die Routendefinition.

Program.cscsharp

var builder = WebApplication.CreateBuilder(args);

// Services für Dependency Injection registrieren
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
builder.Services.AddScoped<IProductRepository, ProductRepository>();

var app = builder.Build();

// Middleware-Pipeline konfigurieren
app.UseExceptionHandler("/error");
app.UseHttpsRedirection();
app.UseAuthorization();

// Minimal API Endpunkt-Definitionen
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();

Dieses Muster zentralisiert die Routendefinitionen und behält gleichzeitig vollen Zugriff auf den Dependency-Injection-Container. Der Parameter IProductRepository demonstriert die konstruktorlose Injektion direkt in Handler-Delegates.

Route Groups und Endpunkt-Organisation

Mit wachsenden Anwendungen wird die Organisation von Endpunkten kritisch. Route Groups, eingeführt in .NET 7, bieten Namespacing und gemeinsame Konfiguration ohne den minimalen Ansatz aufzugeben.

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);
    }
}

Durch den Aufruf von app.MapProductEndpoints() in Program.cs werden alle Produkt-Routen mit gemeinsamen Autorisierungsanforderungen und OpenAPI-Metadaten registriert. Diese Struktur skaliert gut für Anwendungen mit Hunderten von Endpunkten.

Parameter-Binding und Validierung

Minimal APIs unterstützen mehrere Binding-Quellen: Route-Parameter, Query-Strings, Header, Request-Bodies und Services aus dem DI-Container. Das Verständnis der Binding-Priorität verhindert häufige Fallstricke in technischen Interviews.

Program.cs - Parameter-Binding-Beispielecsharp

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

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

// Komplexes Model-Binding mit Validierung
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);
});

Das Attribut [FromBody] ist für komplexe Typen optional, verbessert aber die Lesbarkeit. FluentValidation integriert sich natürlich durch Dependency Injection und hält die Validierungslogik getrennt von den Endpunkt-Handlern.

Binding-Quellen-Priorität

Wenn kein Attribut angegeben wird, leiten Minimal APIs die Binding-Quellen ab: zuerst Route-Parameter, dann Query-Strings für einfache Typen und Request-Body für komplexe Typen. Explizite Attribute wie [FromQuery] oder [FromBody] überschreiben dieses Verhalten.

Performance-Optimierung mit Native AOT

.NET 8 führte Native AOT (Ahead-of-Time) Kompilierungsunterstützung für Minimal APIs ein und produziert eigenständige ausführbare Dateien mit Startzeiten im Sub-Millisekundenbereich. Diese Fähigkeit macht Minimal APIs ideal für Serverless-Deployments, bei denen die Cold-Start-Latenz entscheidend ist.

Program.cs - AOT-kompatible Konfigurationcsharp

var builder = WebApplication.CreateSlimBuilder(args);

// AOT-freundliche JSON-Serialisierung
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();

// Quellcode-generierter JSON-Serializer-Kontext
[JsonSerializable(typeof(HealthResponse))]
[JsonSerializable(typeof(Product))]
[JsonSerializable(typeof(List<Product>))]
internal partial class AppJsonContext : JsonSerializerContext { }

public record HealthResponse(string Status, DateTime CheckedAt);

Die Methode CreateSlimBuilder schließt unnötige Framework-Funktionen aus, während der quellcode-generierte JsonSerializerContext die Laufzeit-Reflektion für die JSON-Serialisierung eliminiert. Veröffentlichte AOT-Binärdateien für einfache APIs messen typischerweise 10-15 MB im Vergleich zu 80+ MB für Standard-Self-Contained-Deployments.

Typed Results und Response-Metadaten

.NET 7 führte TypedResults für die Compile-Zeit-Verifizierung von Response-Typen ein, was die Genauigkeit der OpenAPI-Dokumentation verbessert und Typfehler während der Entwicklung erkennt.

csharp

// Stark typisierte Results mit OpenAPI-Metadaten
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: "Ein Fehler ist beim Abrufen des Produkts aufgetreten",
            statusCode: StatusCodes.Status500InternalServerError);
    }
})
.WithName("GetProductById")
.WithOpenApi(operation =>
{
    operation.Summary = "Ruft ein Produkt anhand der ID ab";
    operation.Description = "Gibt die Produktdetails zurück oder 404 wenn nicht gefunden";
    return operation;
});

Der Union-Typ Results<T1, T2, T3> deklariert alle möglichen Response-Typen, die Swagger/OpenAPI-Generatoren zur Erstellung genauer Dokumentation verwenden. Dieses Muster ist besonders wertvoll bei der Vorbereitung auf ASP.NET Core Interview-Fragen zum API-Design.

Bereit für deine .NET-Interviews?

Übe mit unseren interaktiven Simulatoren, Flashcards und technischen Tests.

.NET erkunden

Endpoint-Filter für übergreifende Belange

Endpoint-Filter bieten Middleware-ähnliche Funktionalität, die auf spezifische Endpunkte oder Gruppen beschränkt ist, und behandeln Belange wie Logging, Caching und Request-Transformation.

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);
    }
}

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

// Globale Filter-Registrierung über 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(
            "Endpunkt {Method} {Path} abgeschlossen in {ElapsedMs}ms",
            context.HttpContext.Request.Method,
            context.HttpContext.Request.Path,
            stopwatch.ElapsedMilliseconds);

        return result;
    });

Filter werden in der Reihenfolge ihrer Registrierung ausgeführt, wobei der innerste Filter dem Endpunkt-Handler am nächsten ist. Diese Architektur ermöglicht eine saubere Trennung von Validierungs-, Logging- und Autorisierungslogik.

Authentifizierungs- und Autorisierungsmuster

Minimal APIs unterstützen dieselben Authentifizierungs- und Autorisierungsmechanismen wie MVC-Controller, mit einer deklarativeren Konfigurationssyntax.

Program.cs - JWT-Authentifizierungs-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();

// Geschützte Endpunkte
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();

// Anonymer Endpunkt innerhalb einer geschützten Gruppe
var protectedGroup = app.MapGroup("/api/secure")
    .RequireAuthorization();

protectedGroup.MapGet("/public-info", () => Results.Ok("Dies ist öffentlich"))
    .AllowAnonymous();

Die Erweiterungsmethode RequireAuthorization akzeptiert Policy-Namen oder kann ohne Argumente aufgerufen werden, um einen beliebigen authentifizierten Benutzer zu erfordern. Das Verständnis dieser Muster ist essenziell für Authentifizierungs- und Autorisierungs-Interview-Fragen.

Interview-Fragen: Häufige Muster

Technische Interviews untersuchen häufig die Unterschiede zwischen Minimal APIs und traditionellen Controllern. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen:

| Aspekt | Minimal APIs | MVC Controller | |--------|--------------|----------------| | Boilerplate | Niedrig - direkte Handler-Delegates | Höher - Klasse + Methode + Attribute | | Routing | Inline mit MapGet, MapPost | Attribut- oder konventionsbasiert | | Model Binding | Automatisch mit optionalen Attributen | Konvention + Attribute | | Filter | Endpoint-Filter | Action-Filter + Middleware | | AOT-Unterstützung | Volle Unterstützung seit .NET 8 | Eingeschränkt, reflektionslastig | | Testbarkeit | Funktionsbasiert, einfach zu testen | Erfordert Controller-Instanziierung | | Geeignet für | Microservices, einfache APIs | Große Anwendungen, komplexe Workflows |

Interview-Tipp

Wenn gefragt wird "Wann würden Sie Controller gegenüber Minimal APIs bevorzugen?", erwähnen Sie komplexe Anwendungen, die Action-Filter, Model-Binding-Anpassungen oder bestehende Codebasen mit etablierten MVC-Mustern erfordern. Minimal APIs eignen sich hervorragend für Greenfield-Microservices und Serverless-Funktionen.

Testen von Minimal API Endpunkten

Integrationstests mit WebApplicationFactory bieten realistische Endpunkt-Verifikation ohne Deployment der Anwendung.

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 =>
            {
                // Echtes Repository durch Mock ersetzen
                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-Produkt", 29.99m, "Test-Beschreibung");

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

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

Für eine tiefere Erkundung von Clean Architecture Mustern in .NET-Anwendungen sollte die Service-Schicht unabhängig mit Unit-Tests getestet werden, während Integrationstests die vollständige Request-Pipeline verifizieren.

Fazit

Minimal APIs repräsentieren den modernen Ansatz zur Erstellung von HTTP-Services in ASP.NET Core:

Route Groups und Endpunkt-Organisation skalieren von einfachen Microservices zu komplexen Anwendungen
Endpoint-Filter bieten saubere Trennung von übergreifenden Belangen wie Validierung und Logging
TypedResults ermöglichen Compile-Zeit-Verifikation von Response-Typen und genaue OpenAPI-Dokumentation
Native AOT-Kompilierung liefert Sub-Millisekunden-Startzeiten für Serverless-Deployments
Integrationstests mit WebApplicationFactory gewährleisten realistische Endpunkt-Verifikation

Für die Interview-Vorbereitung sollte der Fokus darauf liegen, zu erklären, wann Minimal APIs gegenüber traditionellen Controllern angemessen sind, und Verständnis für die Request-Pipeline, Dependency Injection und Authentifizierungsmuster zu demonstrieren.

Fang an zu üben!

Teste dein Wissen mit unseren Interview-Simulatoren und technischen Tests.

Kostenloses Konto erstellen

ASP.NET Core Minimal APIs 2026: Architektur, Performance und Interview-Fragen