Absolutely. Here is a practical ASP.NET Core interview question set, organized from beginner to advanced. It covers topics commonly asked for ASP.NET Core Web API, MVC, Minimal APIs, Entity Framework Core, authentication/authorization, dependency injection, middleware, performance, and .NET 10.

ASP.NET Core Basics Interview Questions

ASP.NET Core basics questions are usually the first step in an interview because they help the interviewer understand how strong your fundamental knowledge of the framework is. Questions about Program.cs, middleware, the request pipeline, dependency injection, configuration, hosting, routing, and environments may seem simple, but your answers reveal whether you understand how an ASP.NET Core application actually works behind the scenes. These questions also help the interviewer judge your technical foundation, clarity of concepts, practical experience, and ability to explain technical topics, rather than simply checking whether you have memorized definitions. A strong understanding of these fundamentals will also make it much easier to answer advanced ASP.NET Core questions later in the interview.

1. What is ASP.NET Core and it’s advantages over ASP.NET Framework? Also explain difference between .NET Core, and modern .NET?

ASP.NET Core is a cross-platform, open-source, high-performance framework from Microsoft for building modern web applications, RESTful Web APIs, Minimal APIs, MVC applications, real-time applications, and other server-side web solutions. It runs on Windows, Linux, and macOS and is part of the modern unified .NET platform.

ASP.NET Core was designed as a successor to the older ASP.NET Framework, addressing several of its limitations while providing better performance, flexibility, scalability, and support for modern application development.

The biggest difference is that ASP.NET Core is a modern, cross-platform, high-performance framework designed for today’s cloud, container, API, and web application development, whereas ASP.NET Framework is the older Windows-focused web framework.

For new applications, ASP.NET Core is generally the preferred choice, while ASP.NET Framework remains relevant when maintaining existing legacy applications or applications that depend on technologies available only in the .NET Framework.

.NET Core was the name used for Microsoft’s cross-platform .NET platform from versions 1.0 through 3.1. Starting with .NET 5, Microsoft unified the platform and dropped the “Core” name. Therefore, .NET 5 and later—including .NET 10—are simply called .NET. ASP.NET Core, however, retained the “Core” name. So today, you should generally say “.NET 10”, not “.NET Core 10”.

2. What is Program.cs in ASP.NET Core, WebApplication, and explain the purpose of WebApplicationBuilder ?

Program.cs is the entry point of an ASP.NET Core application. Since .NET 6, it uses a minimal hosting model — meaning all the setup that used to be spread across Program.cs (with ConfigureServices and Configure methods) is now consolidated into a single file with top-level statements (no Main method or class boilerplate required).

A typical modern Program.cs looks like this:

var builder = WebApplication.CreateBuilder(args);

// Register services (dependency injection container)
builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("Default")));

var app = builder.Build();

// Configure the HTTP request pipeline (middleware)
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

It handles three jobs in sequence: build configuration and register services, build the app, then configure the middleware pipeline and start listening for requests.

What is WebApplication ?

WebApplication is the object you get back after calling builder.Build() on a WebApplicationBuilder. It represents your fully configured, ready-to-run application, and it’s what you use to define the HTTP request pipeline and start the server.

var builder = WebApplication.CreateBuilder(args);
// ... register services on builder.Services ...

var app = builder.Build(); // <-- this is the WebApplication

// From here on, you configure app, not builder
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

WebApplication implements several interfaces at once, which is why it can do so much with one object:

1. IHost — it’s the application host, so it manages the app’s lifetime (starting, running, stopping, graceful shutdown).
2. IApplicationBuilder — this is what lets you build the middleware pipeline using app.Use…() methods (UseRouting, UseAuthentication, UseHttpsRedirection, custom middleware via app.Use(…), etc.). Middleware runs in the order you add it, for every incoming request.
3. IEndpointRouteBuilder — this is what lets you map endpoints directly on it: app.MapGet(…), app.MapControllers(), app.MapRazorPages(), app.MapHub<t>(), etc.

What you typically do with it:

1. Read environment info — app.Environment.IsDevelopment(), IsProduction(), etc., to conditionally add middleware.
2. Configure the middleware pipeline.
3. Map endpoints — minimal APIs directly, or MVC/Razor Pages routes.
4. Access services — via app.Services (an IServiceProvider), useful for things like running startup logic or seeding a database.
5. Run the app — app.Run() starts listening for requests and blocks until shutdown. There’s also app.RunAsync() and app.Start()/app.StopAsync() for more control.

Purpose of WebApplicationBuilder

WebApplicationBuilder (created via WebApplication.CreateBuilder(args)) is the object responsible for assembling everything the app needs before it starts running. It bundles together several things that used to be configured separately:

1. Configuration — automatically loads settings from appsettings.json, appsettings.{Environment}.json, environment variables, command-line args, and user secrets, all merged into builder.Configuration.
2. Dependency Injection container — builder.Services is an IServiceCollection where you register your services, repositories, DbContexts, HttpClients, etc. so they can be injected elsewhere in the app.
3. Logging — builder.Logging lets you configure logging providers (console, debug, event source, etc.) out of the box. Web server setup — configures Kestrel (the built-in web server) and host settings like URLs, content root, and environment name (Development/Staging/Production).

Once you’ve configured everything on the builder, you call builder.Build(), which returns a WebApplication instance — this represents the fully configured app, and it’s what you use afterward to set up middleware (app.Use..) and endpoints (app.Map..) before calling app.Run().

In short: WebApplicationBuilder is a single unified object that replaces the old IWebHostBuilder/IHostBuilder split, making it much simpler to configure services, configuration, and logging in one place before the app is built and started.

3. What is Kestrel ?

Kestrel is the built-in, cross-platform web server used by ASP.NET Core to handle HTTP requests. It’s the default server that gets automatically configured and started for you when you call app.Run() — you don’t need to install IIS, Apache, or anything else to run an ASP.NET Core app. Key characteristics are:

1. Cross-platform — Kestrel runs on Windows, Linux, and macOS, since it’s built on top of libuv/managed sockets (in newer versions, it uses a fully managed socket implementation) rather than any OS-specific web server technology.
2. Fast and lightweight — it’s optimized for throughput and is one of the fastest .NET web servers, benchmarked regularly in the TechEmpower benchmarks.
3. Included by default — when you call WebApplication.CreateBuilder(args), Kestrel is configured automatically as the web server. You don’t add it explicitly in most apps.
4. Not always exposed directly to the internet — in production, Kestrel is often run behind a reverse proxy like:
   • IIS (on Windows)
   • Nginx or Apache (on Linux)
   • Azure App Service’s built-in proxy

The reverse proxy handles things like SSL termination, request buffering, load balancing across multiple Kestrel instances, and serving static files more efficiently — while Kestrel focuses purely on handling the ASP.NET Core application logic. That said, Kestrel is robust enough to be exposed directly to the internet these days (it has built-in support for HTTPS, HTTP/2, HTTP/3, connection limits, timeouts, etc.), so this pattern is now optional rather than mandatory.

How you configure it:

You can customize Kestrel through builder.WebHost.ConfigureKestrel(…) or in appsettings.json:

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(options =>
{
    options.ListenAnyIP(5000); // HTTP
    options.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps(); // HTTPS
    });

    options.Limits.MaxConcurrentConnections = 100;
    options.Limits.MaxRequestBodySize = 10 * 1024 * 1024; // 10 MB
});

Or via configuration:

{
  "Kestrel": {
    "Endpoints": {
      "Http": {
        "Url": "http://localhost:5000"
      },
      "Https": {
        "Url": "https://localhost:5001"
      }
    }
  }
}

Where it fits in the pipeline:

Client Request
      ↓
[Reverse Proxy - optional] (Nginx / IIS / Azure)
      ↓
   Kestrel  ← low-level HTTP server, receives raw requests
      ↓
Middleware Pipeline (app.Use...)
      ↓
Endpoints (app.Map... / Controllers)

In short: Kestrel is the actual server process listening on a port and translating raw HTTP traffic into requests that flow through your ASP.NET Core middleware pipeline. It’s what makes app.Run() actually able to “run” — without it, there’d be nothing accepting connections.

4. What is the ASP.NET Core request pipeline?

The request pipeline is the sequence of middleware components that every incoming HTTP request passes through before a response is generated and sent back. Each middleware can inspect, modify, short-circuit, or pass along the request — and then do the same on the way back out.

A typical pipeline in Program.cs:

var app = builder.Build();

app.UseExceptionHandler("/Error");   // catches exceptions from everything below
app.UseHsts();                       // adds HSTS header (production)

app.UseHttpsRedirection();           // redirect HTTP -> HTTPS
app.UseStaticFiles();                // serve wwwroot files, short-circuits if found

app.UseRouting();                    // determines which endpoint matches the URL

app.UseCors();                       // apply CORS policy
app.UseAuthentication();             // who are you? (sets HttpContext.User)
app.UseAuthorization();              // are you allowed? (checks policies)

app.MapControllers();                // executes the matched endpoint
app.Run();

Middleware executes in the order it’s registered, and typically in a “pipeline” shape:

For example, UseAuthentication() must come before UseAuthorization(), and both generally come after UseRouting() but before UseEndpoints().

5. What is the difference between Use, Run, and Map?

These are the three core extension methods (from IApplicationBuilder) for building the middleware pipeline. They differ in whether they call the next middleware, whether they branch, and how they match requests.

Use — chain middleware, call next()

Use adds middleware to the pipeline that can call the next middleware and continue the chain. This is the most common one.

app.Use(async (context, next) =>
{
    Console.WriteLine("Before");
    await next(); // passes control to the next middleware
    Console.WriteLine("After");
});

• Can inspect/modify the request before next().
• Can inspect/modify the response after next() returns.
• Can choose not to call next() (short-circuit), though that’s more Run’s job conceptually.
• Multiple Use calls form a chain, each wrapping the next.

Run — terminal middleware, no next

Run adds terminal middleware — it does not receive a next parameter at all, because it’s meant to end the pipeline. Whatever is registered after a Run will never execute for that branch.

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello, this is the end of the line.");
});

• No way to call anything further — it’s a dead end by design.
• Typically used as the last piece of a pipeline or a branch (e.g., inside Map/MapWhen).
• If you add middleware after app.Run(), it’s simply never reached — the compiler won’t stop you, but it’s dead code.

Map — branch the pipeline by path

Map creates a separate sub-pipeline based on a matching request path. Once a request matches, it’s routed into that branch instead of continuing in the main pipeline.

app.Map("/admin", adminApp =>
{
    adminApp.Use(async (context, next) =>
    {
        Console.WriteLine("Inside /admin branch");
        await next();
    });

    adminApp.Run(async context =>
    {
        await context.Response.WriteAsync("Admin area");
    });
});

app.Run(async context =>
{
    await context.Response.WriteAsync("Main pipeline");
});

• Matches based on the path segment (/admin, /api, etc.) — it strips the matched segment off PathBase for the branch.
• Once branched, that request stays in the branch’s pipeline (it doesn’t automatically rejoin the main one).
• There’s also MapWhen(), which branches based on any condition, not just path.

Important distinction: this is different from app.MapGet/MapControllers

Don’t confuse app.Map(…) (pipeline branching, from “IApplicationBuilder”) with app.MapGet(…), app.MapPost(…), app.MapControllers() (from IEndpointRouteBuilder) — the endpoint routing methods used after UseRouting(). Those register actual endpoints (minimal APIs, controllers) rather than branching middleware.

app.UseRouting();

app.MapGet("/hello", () => "Hi!");   // endpoint mapping, not pipeline branching
app.MapControllers();                 // endpoint mapping

6. What is Routing also explain endpoint routing. What does app.UseRouting() do ?

Routing is the process by which ASP.NET Core matches an incoming HTTP request to an endpoint — a piece of code that can handle that request (a controller action, Razor Page, minimal API delegate, gRPC service, etc.).

It looks at things like:

• The URL path (/products/5).
• The HTTP method (GET, POST, etc).
• Sometimes headers, query strings, or route constraints.

…and decides which handler should execute, and extracts parameters from the URL (like id = 5) to pass into that handler.

What is Endpoint Routing ?

Before ASP.NET Core 2.2, routing and execution were tightly coupled — the router matched a route and immediately dispatched to a handler in one step. This made it hard for other middleware (like CORS, Authorization) to know in advance which endpoint would run, because that information wasn’t available until the MVC middleware itself resolved it.

Endpoint Routing (introduced in 2.2, standard since 3.0) splits this into two distinct phases:

1. Route Matching — figure out which endpoint matches the request, and expose that as HttpContext.GetEndpoint().
2. Route Execution — actually invoke that endpoint.

Because these are now separate, middleware placed between matching and execution can inspect the selected endpoint (and its metadata, like [Authorize] attributes) and make decisions accordingly — without having to duplicate routing logic itself.

Why this matters (good interview point):

What does app.UseRouting() do?

app.UseRouting() adds the route matching middleware to the pipeline. It:

• Looks at the incoming request.
• Matches it against the registered route patterns (from MapControllers(), MapGet(), MapRazorPages(), etc.)
• Sets HttpContext.GetEndpoint() to the matched endpoint.
• Does NOT execute the endpoint yet — it just identifies it.

The actual execution happens later — either implicitly via app.MapControllers() / app.MapGet() (in .NET 6+ minimal hosting), or explicitly via app.UseEndpoints(…) in older Program.cs / Startup.cs style.

Typical middleware order (very commonly asked):

app.UseRouting();          // 1. Match the request to an endpoint

app.UseCors();             // 2. Runs AFTER routing, BEFORE execution —
app.UseAuthentication();   //    these can inspect the matched endpoint
app.UseAuthorization();    //    (e.g., check [Authorize] metadata)

app.MapControllers();      // 3. Execute the matched endpoint

Why order matters (classic gotcha question):

If you call UseAuthorization() before UseRouting(), it will throw an exception or fail to work correctly — because at that point, no endpoint has been matched yet, so there’s no metadata (like [Authorize]) for the authorization middleware to inspect.

7. What is app.UseAuthentication() and app.UseAuthorization() ?

app.UseAuthentication() adds the authentication middleware to the pipeline. Its job is to figure out “who is making this request?”

• It examines the incoming request (cookies, JWT bearer tokens, headers, etc).
• Runs the configured authentication scheme(s) (Cookie, JWT Bearer, OAuth, OpenID Connect, etc).
• If valid credentials are found, it constructs a ClaimsPrincipal and attaches it to HttpContext.User.
• If no valid credentials exist, HttpContext.User is set to an unauthenticated ClaimsPrincipal (not null — just IsAuthenticated == false).

builder.Services.AddAuthentication("Bearer")
    .AddJwtBearer();

app.UseAuthentication(); // sets HttpContext.User

app.UseAuthorization() adds the authorization middleware. Its job is to figure out “are you allowed to do this?”

• It looks at HttpContext.User (populated by authentication).
• Checks it against the requirements of the matched endpoint — e.g., [Authorize], [Authorize(Roles = “Admin”)], or policy-based requirements.
• If the user doesn’t meet the requirements → returns 403 Forbidden (or 401 Unauthorized if not authenticated at all).
• If they do → request proceeds to the endpoint.

[Authorize(Roles = "Admin")]
public IActionResult DeleteUser(int id) { ... }

Why Order Matters (classic gotcha):

app.UseRouting();          // 1. Match request to endpoint (sets HttpContext.GetEndpoint())
app.UseAuthentication();   // 2. Determine WHO the user is → sets HttpContext.User
app.UseAuthorization();    // 3. Determine IF that user can access the matched endpoint
app.MapControllers();      // 4. Execute the endpoint

Key rules:

• UseAuthentication() must come before UseAuthorization() — you can’t authorize a user you haven’t identified yet.
• Both must come after UseRouting() — authorization needs to know which endpoint was matched (to read its [Authorize] metadata), which is only known after routing runs.
• Both must come before MapControllers() / endpoint execution — otherwise the checks never happen before the code runs.

If you get the order wrong, ASP.NET Core will often literally throw a runtime exception telling you to fix the middleware order (there’s a diagnostic check for this).

8. What is the difference between IHostEnvironment and IWebHostEnvironment ?

IHostEnvironment is a generic interface providing information about the hosting environment for any .NET generic host — not specific to web apps. It’s part of Microsoft.Extensions.Hosting, used by console apps, worker services, and web apps alike.

public interface IHostEnvironment
{
    string EnvironmentName { get; set; }     // Development, Staging, Production
    string ApplicationName { get; set; }      // Assembly/app name
    string ContentRootPath { get; set; }      // Root folder for content files
    IFileProvider ContentRootFileProvider { get; set; }
}

Use case: Any generic host app (worker service, background service, console app) that just needs to know the environment name or content root — no concept of “web” involved.

IWebHostEnvironment is a web-specific extension of IHostEnvironment, part of Microsoft.AspNetCore.Hosting. It adds properties relevant only to web applications — specifically, serving static files.

public interface IWebHostEnvironment : IHostEnvironment
{
    string WebRootPath { get; set; }          // wwwroot folder path
    IFileProvider WebRootFileProvider { get; set; }
}

Use case: ASP.NET Core web apps that need to know where wwwroot is, to serve static files (CSS, JS, images).

9. What is IConfiguration?

IConfiguration is the core abstraction in ASP.NET Core for accessing configuration data — key/value settings your app needs at runtime — regardless of where that data actually comes from.

It’s part of Microsoft.Extensions.Configuration and is populated by the Generic Host before your app even starts handling requests.

Where the data comes from (Configuration Providers):

By default, WebApplicationBuilder wires up multiple providers, layered in this order (later ones override earlier ones):

• appsettings.json
• appsettings.{Environment}.json
• User Secrets (Development only)
• Environment variables
• Command-line arguments

var builder = WebApplication.CreateBuilder(args);
// builder.Configuration is already an IConfiguration built from the above sources

You can also add custom sources: Azure Key Vault, a database, XML/INI files, in-memory collections, etc.

10. What is appsettings.json ? How do environment-specific configuration files work ?

appsettings.json is the default configuration file in ASP.NET Core — a JSON file at the root of the project used to store application settings (connection strings, logging levels, feature flags, custom settings, etc.). It’s automatically loaded as one of the configuration providers when you call WebApplication.CreateBuilder(args).

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "ConnectionStrings": {
    "DefaultConnection": "Server=.;Database=MyDb;Trusted_Connection=True;"
  },
  "AllowedHosts": "*"
}

Alongside appsettings.json, you can have environment-specific overrides:

appsettings.json                 ← base settings, always loaded
appsettings.Development.json     ← loaded only when EnvironmentName = "Development"
appsettings.Staging.json         ← loaded only when EnvironmentName = "Staging"
appsettings.Production.json      ← loaded only when EnvironmentName = "Production"

How the environment is determined: Set via the ASPNETCORE_ENVIRONMENT (or DOTNET_ENVIRONMENT) environment variable — commonly Development, Staging, or Production. Locally, this is usually set in launchSettings.json.

Load Order & Merging (the key interview point):

WebApplication.CreateBuilder(args) wires these up in a specific order, and later sources override earlier ones on matching keys:

1. appsettings.json
2. appsettings.{EnvironmentName}.json
3. User Secrets (Development only)
4. Environment variables
5. Command-line arguments

Example of the merge behavior

appsettings.json:

{
  "Logging": { "LogLevel": { "Default": "Information" } },
  "ApiUrl": "https://api.prod.example.com"
}

appsettings.Development.json:

{
  "Logging": { "LogLevel": { "Default": "Debug" } }
}

Result when running in Development:

{
  "Logging": { "LogLevel": { "Default": "Debug" } },   // overridden
  "ApiUrl": "https://api.prod.example.com"               // inherited from base
}

How It’s Registered (behind the scenes) – WebApplication.CreateBuilder(args) does roughly this internally:

config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);
config.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);
if (env.IsDevelopment())
{
    config.AddUserSecrets(...);
}
config.AddEnvironmentVariables();
config.AddCommandLine(args);

• optional: true → the app won’t crash if, say, appsettings.Production.json doesn’t exist.
• reloadOnChange: true → the file is watched; if it changes on disk while the app is running, IConfiguration picks up the new values (paired with IOptionsMonitor for live updates in your code).

Dependency Injection Interview Questions

Dependency Injection questions are a staple in ASP.NET Core interviews because DI isn’t just a supporting feature — it’s baked into the framework’s core architecture. Interviewers ask about it to see whether you understand why the framework is built the way it is, not just that you can inject an interface into a constructor. Your answer reveals whether you grasp concepts like loose coupling, testability, service lifetimes (Singleton/Scoped/Transient), the composition root, and how ASP.NET Core’s own internals (logging, configuration, EF Core) are wired using the same container. A clear, structured answer here signals real hands-on experience rather than memorized definitions, and it sets you up well for follow-up questions on service lifetimes, captive dependencies, and the options pattern.

11. What is Dependency Injection(DI) ? Why DI is used in ASP.NET Core ? Explain the three DI lifetimes?

Dependency Injection is a design pattern where an object’s dependencies (the other objects/services it needs to function) are provided to it from the outside, rather than the object creating them itself.

Instead of this (tight coupling):

public class OrderService
{
    private readonly EmailService _emailService = new EmailService(); // hardcoded dependency
}

You do this (loose coupling):

public class OrderService
{
    private readonly IEmailService _emailService;

    public OrderService(IEmailService emailService) // injected via constructor
    {
        _emailService = emailService;
    }
}

The class depends on an abstraction (IEmailService), and something external — a DI container — decides which concrete implementation to hand it at runtime.

Why is DI used in ASP.NET Core ?

ASP.NET Core has DI built into the framework itself (not bolted on like older versions needed third-party tools such as Autofac or Ninject). Reasons it’s used:

• Loose coupling — classes depend on interfaces, not concrete implementations, making code easier to change.
• Testability — you can inject mock/fake implementations in unit tests instead of real services (e.g., mock a database call).
• Maintainability — swapping an implementation (e.g., switching from SendGrid to SMTP for emails) means changing one registration line, not every class that uses it.
• Centralized object lifetime management — the DI container manages creation and disposal of objects, so you’re not manually managing new and cleanup everywhere.
• Framework-wide consistency — built-in services like ILogger, DbContext, IConfiguration, HttpClient are all provided via DI, so your custom services follow the same pattern.

Registration happens in Program.cs:

builder.Services.AddScoped<IEmailService, EmailService>();

Explain the three DI lifetimes

• A new object is created every single time it’s injected — even multiple times within the same request.
• Best for small, stateless, cheap-to-create services.

builder.Services.AddTransient<IEmailService, EmailService>();

• One instance is created per HTTP request. If the same service is requested multiple times within that request, the same instance is reused.
• Classic example: DbContext in EF Core — you want the same context throughout a request to track changes consistently, but not share it across requests (which would cause concurrency issues).

builder.Services.AddScoped<IOrderRepository, OrderRepository>();

• Only one instance for the entire lifetime of the application — created once, reused for every request by every user.
• Good for: caching services, configuration objects, logging providers.
• ⚠️ Risk: if a singleton holds a reference to a scoped service (like DbContext), you get a captive dependency bug — the short-lived service gets trapped inside the long-lived one, causing threading/data issues.

builder.Services.AddSingleton<ICacheService, CacheService>();

Follow-up traps interviewers often ask:

• “What happens if you inject a scoped service into a singleton?” → Runtime exception (or captive dependency bug if done incorrectly via IServiceProvider).
• “Is DbContext scoped or transient by default?” → Scoped, via AddDbContext<>().
• “Can you manually resolve a service instead of constructor injection?” → Yes, via IServiceProvider.GetService<t>() (service locator pattern — generally discouraged).
• “What’s the difference between DI and IoC (Inversion of Control)?” → DI is one way to implement the broader IoC principle.

12. When should you use a Singleton service ?

Use Singleton when the service should be created once for the entire application lifetime and shared across all requests and all users.

Good use cases:

• Stateless, thread-safe utility services — e.g., a service that just does computation with no mutable shared state (ILogger-style helpers, mapping utilities).
• In-memory caching services — e.g., IMemoryCache itself is registered as a singleton; a custom cache wrapper that holds data across requests.
• Configuration/settings objects that are read-only after startup (e.g., wrapping IOptions values you don’t expect to change).
• Connection pools / expensive-to-create shared resources — e.g., an HttpClient factory setup, a database connection pool manager, or a third-party SDK client that’s explicitly documented as thread-safe and meant to be reused.
• Application-wide counters, background job schedulers, or shared state coordinators — e.g., a service tracking metrics across the app, or a coordinator for a BackgroundService.
• Expensive initialization — if constructing the service is costly (loading large data, compiling regex, etc.), singleton avoids repeating that cost per request.

Key requirement: thread safety:

Because a singleton instance is shared across concurrent requests, it must be thread-safe. Any mutable state inside it needs proper synchronization (locks, ConcurrentDictionary, immutable data structures, etc.), or you risk race conditions.

When NOT to use Singleton:

• If the service depends on Scoped services (like DbContext), don’t make it a singleton — this causes the classic “captive dependency” problem, where the scoped service gets trapped inside a singleton and effectively becomes a singleton too, often causing bugs (e.g., a DbContext used across threads/requests incorrectly).
• If the service holds per-request or per-user state — use Scoped instead.
• If it has cheap-to-create, non-thread-safe logic with no shared state — Transient is simpler and safer.

Interview-ready summary:

Use Singleton for stateless or thread-safe shared services that are expensive to create or need to maintain state across the entire app lifetime — like caching, configuration, or connection pooling — while making sure they never directly depend on Scoped services like DbContext.

13. Why is DbContext normally registered as Scoped ?

a. It maps naturally to a single unit of work:

A web request typically represents one logical “unit of work” — read some data, maybe modify it, save changes, done. DbContext is designed around this same idea: it tracks changes to entities, batches them, and commits them together via SaveChanges(). Scoping it to the request means each request gets a clean, isolated unit of work that starts and ends with the request.

b. DbContext is not thread-safe

A single DbContext instance cannot be used by multiple threads concurrently — EF Core will throw exceptions if you try. If it were a Singleton, every concurrent request would share the same instance and could corrupt or crash things under load. Scoped guarantees each request gets its own instance, so there’s no cross-request interference.

c. Change tracking needs a clear boundary

DbContext keeps an internal cache of entities it’s tracking (the change tracker). If it lived for the whole app lifetime (Singleton), this cache would grow unbounded and get stale — you’d risk serving outdated data or accidentally saving changes that belong to a completely different request/user.

d. Avoids “captive dependency” problems

If DbContext were Scoped but got injected into a Singleton service, it would become a captive dependency — trapped inside the singleton for the app’s whole life, defeating its purpose and likely causing threading/staleness bugs. Keeping DbContext itself Scoped, and being careful about what depends on it, keeps this boundary clean.

e. Matches connection lifetime expectations

Scoped lifetime aligns well with how the underlying database connection should be used — opened for the duration of the request/unit of work, then released back to the pool. Not held open indefinitely (Singleton), and not needlessly reopened many times within the same logical operation (which could happen if it were Transient and injected into multiple places within one request).

14. What is constructor injection ? Can ASP.NET Core perform property injection ?

Constructor injection is a dependency injection technique where a class receives its dependencies as parameters through its constructor, rather than creating them itself or having them set via properties/methods.

public class OrderService
{
    private readonly ILogger<OrderService> _logger;
    private readonly IEmailSender _emailSender;

    // Dependencies are "injected" through the constructor
    public OrderService(ILogger<OrderService> logger, IEmailSender emailSender)
    {
        _logger = logger;
        _emailSender = emailSender;
    }

    public void PlaceOrder()
    {
        _logger.LogInformation("Order placed");
        _emailSender.Send("Order confirmed");
    }
}

Instead of OrderService doing new EmailSender() internally, it declares “I need an an IEmailSender to function” — and something external (the DI container) supplies them when creating the object.

How it works in ASP.NET Core:

a. You register the dependency and its implementation in Program.cs:

builder.Services.AddScoped<IEmailSender, EmailSender>();
builder.Services.AddScoped<OrderService>();

b. When you ask the container to create an OrderService (e.g., because it’s injected into a controller), it:

• Looks at the constructor – See it needs ILogger<OrderService> and IEmailSender
• Resolves those from the container (recursively resolving their dependencies too)
• Passes them into the constructor
• Returns you a fully-constructed OrderService.

public class OrdersController : ControllerBase
{
    private readonly OrderService _orderService;

    public OrdersController(OrderService orderService) // <- injected automatically
    {
        _orderService = orderService;
    }
}

Why it’s preferred (key interview points):

ASP.NET Core and Property Injection

ASP.NET Core’s built-in dependency injection (DI) container does not support property injection out of the box. It only supports constructor injection.

The built-in IServiceProvider/IServiceCollection container resolves dependencies exclusively by looking at a class’s constructor parameters. If you have a public property decorated with something like [Inject] (as you might see in other frameworks or in Blazor components), the core DI container will simply ignore it — it won’t populate that property automatically.

public class MyService
{
    // This will NOT be automatically injected by the built-in container
    public ILogger<MyService> Logger { get; set; }

    // Only this works with built-in DI
    public MyService(ILogger<MyService> logger)
    {
        Logger = logger;
    }
}

Blazor components are a notable exception — they use the [Inject] attribute for property injection, but this is handled by Blazor’s component activation pipeline, not the general-purpose ASP.NET Core DI container.

public class MyComponent : ComponentBase
{
    [Inject]
    public IMyService MyService { get; set; }
}

15. What is IServiceProvider ? What is service resolution ?

IServiceProvider is the core interface in .NET’s dependency injection system that represents a container capable of resolving (creating/retrieving) service instances. It’s the fundamental abstraction that all of ASP.NET Core’s DI is built on top of.

It’s surprisingly simple — just one method:

public interface IServiceProvider
{
    object? GetService(Type serviceType);
}

That’s it. Given a Type, it returns an instance of that type (or null if it’s not registered). Everything else — AddScoped, AddSingleton, constructor injection, etc. — is built as convenience layers on top of this single method.

Relationship to IServiceCollection:

These two work together but serve different roles:

// IServiceCollection: registering
var services = new ServiceCollection();
services.AddScoped<IEmailSender, EmailSender>();

// Build the container -> get an IServiceProvider
IServiceProvider provider = services.BuildServiceProvider();

// IServiceProvider: resolving
var emailSender = provider.GetService<IEmailSender>();

In Program.cs, builder.Services is an IServiceCollection. When you call builder.Build(), ASP.NET Core internally calls BuildServiceProvider() to produce the IServiceProvider that powers the app for its whole lifetime.

What is service resolution ?

Service resolution is the runtime process of the DI container producing an actual instance of a requested type, based on what was registered earlier. It works recursively — the container inspects the requested type’s constructor, resolves each dependency (and their dependencies, and so on), then builds the object graph bottom-up. The instance returned — and whether it’s newly created or reused — depends on the service’s registered lifetime: transient, scoped, or singleton. Resolution typically happens automatically when ASP.NET Core constructs controllers or other framework-managed types, but can also be done manually via IServiceProvider.GetService or GetRequiredService.

// 1. Registration (startup) — just metadata, nothing is created yet
builder.Services.AddScoped<IEmailSender, EmailSender>();
builder.Services.AddScoped<OrderService>();

// 2. Resolution (runtime) — container actually builds the object graph
var orderService = provider.GetRequiredService<OrderService>();

When step 2 runs, the container:

1. Looks up OrderService → finds its constructor needs IEmailSender (and maybe ILogger<OrderService>)
2. Resolves IEmailSender → finds it maps to EmailSender → checks its constructor for dependencies
3. Keeps resolving recursively until every leaf dependency is satisfied
4. Builds the objects bottom-up and passes them into constructors
5. Returns the fully-constructed OrderService

This recursive process is often called building the object graph or dependency graph.

Automatic (most common): The framework resolves for you.

public class OrdersController : ControllerBase
{
    // ASP.NET Core resolves OrderService (and everything it needs)
    // automatically when creating this controller for an incoming request
    public OrdersController(OrderService orderService) { }
}

Manual: You explicitly ask the IServiceProvider to resolve something.

var service = provider.GetRequiredService<OrderService>();

Middleware Interview Questions

Middleware questions come up a lot in ASP.NET Core interviews because they test whether you actually understand the framework rather than just knowing syntax. Here’s why interviewers lean on them:

a. It reveals whether you understand the request pipeline, not just controllers

A lot of developers can write a controller action but have never thought about everything that happens before and after it. Middleware questions expose whether you understand the full lifecycle of a request — which is foundational to debugging real production issues (weird headers, auth failures, CORS errors, etc. almost always trace back to middleware order).

b. Order-of-execution bugs are extremely common in real jobs

Bugs like “authorization isn’t working,” “CORS is broken,” or “exceptions aren’t being caught” are very often just middleware registered in the wrong order. Interviewers ask this because it’s a real, recurring source of production bugs — not an academic gotcha.

c. It tests architectural thinking (separation of concerns)

Knowing why logging/auth/error-handling belong in middleware rather than in every controller shows you understand clean architecture principles — separating cross-cutting concerns from business logic. This is a signal of engineering maturity, not just framework trivia.

d. It’s a natural way to probe DI lifetime understanding too

The classic “middleware constructor runs once, InvokeAsync runs per-request” gotcha tests whether you understand singleton vs. scoped/transient lifetimes — connecting two topics (DI + middleware) in one question. It’s an efficient way for an interviewer to check multiple concepts at once.

e. Custom middleware = a proxy for “can you extend the framework”

Asking you to write custom middleware checks if you can work with the framework’s conventions (the InvokeAsync(HttpContext, RequestDelegate) pattern) rather than fighting against them — a good signal of whether you’ll be productive quickly on a real codebase.

f. It often leads into follow-up questions

Middleware is a great “hub” topic — a good interviewer will pivot from it into:

• Exception handling strategies.
• (UseExceptionHandler vs. try/catch) Authentication/authorization pipeline CORS configuration.
• Short-circuiting and performance implications Filters vs. middleware (a classic follow-up: “when would you use an action filter instead of middleware?”).

16. What is middleware ? How does middleware execute ? How do you create custom middleware ?

Middleware is a piece of code that runs on every request (or requests matching some condition), sitting between the raw incoming HTTP request and your endpoint/controller — able to inspect, modify, short-circuit, or pass along the request/response.

ASP.NET Core builds the pipeline by chaining middleware components together, one after another:

Request  →  Middleware A  →  Middleware B  →  Middleware C  →  Endpoint
Response ←  Middleware A  ←  Middleware B  ←  Middleware C  ←  Endpoint

Each middleware component has the chance to:

• Do something before passing control to the next component (on the way in)
• Decide whether to call the next component at all (or short-circuit)
• Do something after the next component finishes (on the way out, with the response)

var app = builder.Build();

app.Use(async (context, next) =>
{
    Console.WriteLine("Before"); // runs on the way in
    await next(context);         // calls the next middleware
    Console.WriteLine("After");  // runs on the way out
});

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello World");
});

app.Run();

For a request, the output would be:

Before
(response generated: "Hello World")
After

Real world examples : Every ASP.NET Core app is built from middleware — you’ve likely used these without necessarily calling them “middleware”:

app.UseHttpsRedirection();   // redirects HTTP -> HTTPS
app.UseStaticFiles();        // serves files from wwwroot
app.UseRouting();            // figures out which endpoint matches the URL
app.UseAuthentication();     // identifies who the user is
app.UseAuthorization();      // checks if they're allowed to access the resource
app.UseCors();               // handles cross-origin request rules
app.MapControllers();        // the "final" middleware that invokes your controller action

How Middleware Executes in ASP.NET Core ?

ASP.NET Core middleware executes as an ordered pipeline of request delegates. Each component can perform logic before and after calling the next middleware via next(), forming a nested chain. Order of registration determines execution order for the request path and the reverse order for the response path. Middleware can also short-circuit the pipeline by not calling next(), which is how things like authentication or static file middleware avoid unnecessary processing.

How do you create custom middleware ?

This is the standard approach for real-world, reusable middleware. No interface is required — just follow a convention:

• Constructor takes RequestDelegate next.
• Public method named Invoke or InvokeAsync that takes HttpContext and returns Task

public class RequestLoggingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<RequestLoggingMiddleware> _logger;

    public RequestLoggingMiddleware(RequestDelegate next, ILogger<RequestLoggingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        _logger.LogInformation("Handling request: {Path}", context.Request.Path);

        await _next(context); // pass control to next middleware

        _logger.LogInformation("Finished handling request. Status: {StatusCode}", 
            context.Response.StatusCode);
    }
}

Register it — typically via an extension method for cleanliness:

public static class RequestLoggingMiddlewareExtensions
{
    public static IApplicationBuilder UseRequestLogging(this IApplicationBuilder builder)
    {
        return builder.UseMiddleware<RequestLoggingMiddleware>();
    }
}

In the Program class:

// Program.cs
app.UseRequestLogging();

17. What is the difference between middleware and filters ?

Both Middleware and Filters let you hook into the request pipeline, but they operate at different levels and have different levels of context awareness.

Filters actually execute inside one particular middleware — the MVC/endpoint-invocation middleware (UseRouting + UseEndpoints, effectively). So the relationship looks like:

Request
  → Middleware 1
    → Middleware 2 (e.g., Routing)
      → Middleware 3 (Endpoint execution)
        → Authorization Filter
          → Resource Filter
            → Model Binding
              → Action Filter (before)
                → Action Method executes
              → Action Filter (after)
            → Exception Filter (if needed)
          → Result Filter (before)
            → Result executes (e.g., serialize to JSON)
          → Result Filter (after)
      ← Middleware 3
    ← Middleware 2
  ← Middleware 1
Response

Filters have multiple specialized stages, which middleware doesn’t have:

1. Authorization Filters — run first, decide if user is allowed
2. Resource Filters — run before model binding (good for caching)
3. Action Filters — run immediately before/after the action method
4. Exception Filters — handle exceptions thrown by action methods
5. Result Filters — run before/after the action result is executed (e.g., before the view/JSON is written to response)

public class LogActionFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        // Before the action method runs — has access to action arguments
        Console.WriteLine($"Executing {context.ActionDescriptor.DisplayName}");
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        // After the action method runs — has access to the result
        Console.WriteLine($"Executed. Result: {context.Result}");
    }
}

Registration options:

[ServiceFilter(typeof(LogActionFilter))]  // on a specific action/controller
public IActionResult Get() => Ok();

// OR globally:
builder.Services.AddControllers(options =>
{
    options.Filters.Add<LogActionFilter>();
});

Use Middleware when:

• Logic applies to all requests regardless of framework (e.g., static files, HTTPS redirection, CORS, logging every request, custom headers)
• You need to short-circuit before reaching MVC at all
• You don’t need action-specific context (route values, model state, action arguments)

Use Filters when:

• You need MVC-specific context (which action is being called, model binding results, [FromBody] arguments)
• You want granular control tied to specific controllers/actions (e.g., [Authorize], validation, response shaping)
• You want cross-cutting logic reusable via attributes on select endpoints only

Interview-ready summary

Middleware operates at the raw ASP.NET Core HTTP pipeline level and runs for every request, with no knowledge of MVC concepts like actions or model binding. Filters run inside the MVC pipeline — specifically inside the endpoint-execution middleware — and have five types (Authorization, Resource, Action, Exception, Result) that hook into specific stages of action execution, giving them access to richer context like action arguments and results. Use middleware for cross-cutting, framework-agnostic concerns; use filters when you need MVC-specific context or want behavior scoped to particular controllers/actions.

18. What is the purpose of Invoke() / InvokeAsync() ?

This is the method that does the actual work of the middleware — it’s the piece the framework calls for every incoming request.

public class CustomMiddleware
{
    private readonly RequestDelegate _next;

    public CustomMiddleware(RequestDelegate next)
    {
        _next = next; // stored once, at startup
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // 1. Logic before passing control forward
        // 2. Call the next component in the pipeline
        await _next(context);
        // 3. Logic after the rest of the pipeline completes
    }
}

InvokeAsync (or Invoke) is:

1. The per-request entry point — called by the ASP.NET Core runtime for every HTTP request that reaches this middleware.
2. Where you receive HttpContext — giving access to the request, response, user, services, etc., for this specific request.
3. Where you call _next(context) — passing control to the next middleware in the pipeline. This is what actually chains everything together.
4. Where before/after logic lives — code before _next() runs on the way “in”; code after _next() runs on the way “out” (response phase).

Why It’s Separate from the Constructor

This is a very common interview follow-up, so it’s worth being precise:

public class AuditMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<AuditMiddleware> _logger; // OK: singleton-safe

    public AuditMiddleware(RequestDelegate next, ILogger<AuditMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    // AppDbContext is scoped — injected here, resolved fresh each request
    public async Task InvokeAsync(HttpContext context, AppDbContext db)
    {
        var user = context.User.Identity?.Name;
        db.AuditLogs.Add(new AuditLog { User = user, Path = context.Request.Path });
        await db.SaveChangesAsync();

        await _next(context);
    }
}

Invoke vs InvokeAsync

• Functionally identical — the framework uses reflection to find either name.
• Convention: use InvokeAsync if the method is asynchronous (returns Task), which is almost always the case since you’re typically awaiting _next(context) or I/O. Invoke (synchronous) is rare in practice.

What Happens Internally:

Under the hood, UseMiddleware<T>() uses reflection to build a RequestDelegate that:

1. Instantiates your middleware class once (passing next + singleton services into the constructor).
2. Wraps a call to InvokeAsync, resolving any additional parameters from HttpContext.RequestServices (the per-request DI scope) each time it’s invoked.

This is effectively how the whole middleware pipeline is just a chain of RequestDelegate (Func<HttpContext, Task>) instances, each closing over the “next” one.

19. What is short-circuiting in middleware ?

Short-circuiting is when a middleware component ends the pipeline early by not invoking next(), meaning subsequent middleware and the endpoint are never reached. It’s used intentionally for things like serving static files, rejecting unauthenticated requests, or returning cached responses — avoiding unnecessary work downstream. The middleware that short-circuits is responsible for writing a complete response itself, since nothing further in the pipeline will run.

app.Use(async (context, next) =>
{
    if (!context.Request.Headers.ContainsKey("X-Api-Key"))
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("API key missing");
        return; // next() is NOT called — pipeline short-circuits here
    }

    await next(context); // only reached if the check passes
});

Everything registered after this middleware — including later middleware and the MVC/endpoint layer — is skipped entirely for this request.

Common Real-World Examples:

20. How would you implement global exception handling middleware ?

This is the modern, framework-supported way — cleaner, testable, and supports multiple chained handlers.

public class GlobalExceptionHandler : IExceptionHandler
{
    private readonly ILogger<GlobalExceptionHandler> _logger;

    public GlobalExceptionHandler(ILogger<GlobalExceptionHandler> logger)
    {
        _logger = logger;
    }

    public async ValueTask<bool> TryHandleAsync(
        HttpContext httpContext,
        Exception exception,
        CancellationToken cancellationToken)
    {
        _logger.LogError(exception, "Unhandled exception");

        var (statusCode, title) = exception switch
        {
            KeyNotFoundException => (StatusCodes.Status404NotFound, "Not Found"),
            ValidationException  => (StatusCodes.Status400BadRequest, "Validation Error"),
            _ => (StatusCodes.Status500InternalServerError, "Server Error")
        };

        httpContext.Response.StatusCode = statusCode;

        await httpContext.Response.WriteAsJsonAsync(new ProblemDetails
        {
            Status = statusCode,
            Title = title,
            Detail = exception.Message,
            Instance = httpContext.TraceIdentifier
        }, cancellationToken);

        return true; // true = handled, stop looking for other handlers
    }
}

Registration in Program.cs:

builder.Services.AddExceptionHandler<GlobalExceptionHandler>();
builder.Services.AddProblemDetails(); // enables standard ProblemDetails responses

var app = builder.Build();

app.UseExceptionHandler(); // uses the registered IExceptionHandler(s)

app.UseHttpsRedirection();
app.UseRouting();
app.MapControllers();

app.Run();

You can register multiple handlers — they’re tried in order until one returns true:

builder.Services.AddExceptionHandler<ValidationExceptionHandler>();
builder.Services.AddExceptionHandler<GlobalExceptionHandler>(); // fallback/catch-all last

21. How can middleware access request and response information ?

In ASP.NET Core, middleware doesn’t get separate req/res parameters. Everything is bundled into a single HttpContext object that’s passed through the pipeline.

public class MyMiddleware
{
    private readonly RequestDelegate _next;

    public MyMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // Access request
        var path = context.Request.Path;
        var method = context.Request.Method;
        var headers = context.Request.Headers;

        // Do something before calling the next middleware
        Console.WriteLine($"{method} {path}");

        await _next(context); // pass control to next middleware

        // Do something after downstream middleware has run
        Console.WriteLine($"Response status: {context.Response.StatusCode}");
    }
}

Key pieces

a. HttpContext

• The single object that wraps everything about the current request/response cycle.
• context.Request → HttpRequest object (path, method, headers, query string, body stream, cookies, etc.)
• context.Response → HttpResponse object (status code, headers, body stream, cookies)
• Also exposes context.User (claims principal), context.Items (per-request key/value bag for passing data between middleware), context.Connection, etc.

b. RequestDelegate _next

• Represents “the rest of the pipeline.” Calling await _next(context) invokes the next middleware.
• Because it’s await ed, code after that call runs after the downstream pipeline completes — this is how you read/modify the response on the way back out (e.g., logging status codes, injecting headers based on the final response).

c. Reading the request

   var token = context.Request.Headers["Authorization"];
   var body = await new StreamReader(context.Request.Body).ReadToEndAsync();

d. Modifying the response

context.Response.StatusCode = 401;
context.Response.Headers["X-Custom"] = "value";
await context.Response.WriteAsync("Unauthorized");

Note: once context.Response.Body has started being written to (headers flushed), you can no longer change the status code or headers — a common gotcha interviewers like to probe.

e. Short-circuiting

• A middleware can choose not to call _next(context) at all, ending the pipeline early (e.g., auth failure, rate limiting, serving a cached response).

f. Registration order matters

• Middleware is wired up in Program.cs/Startup.cs via app.Use…() calls, and executes in that exact order on the way in, then unwinds in reverse order on the way out (it’s effectively a nested/recursive chain, not a flat list).

g. Alternative styles

• Besides the class-based convention above, ASP.NET Core also supports inline delegate middleware:

app.Use(async (context, next) =>
{
    // before
    await next();
    // after
});

• And IMiddleware (factory-based) for DI-friendly, per-request instantiated middleware.

22. Why Exception-Handling Middleware Goes Early in the Pipeline ?

The key reason: middleware can only catch exceptions thrown by components that run after it in the pipeline.

ASP.NET Core middleware forms a nested call chain via await _next(context). If middleware A calls middleware B which calls middleware C, and C throws, that exception propagates back up through B and then A — but only if A and B are “wrapping” C, i.e., positioned before it in registration order.

app.UseExceptionHandler("/Error");   // registered early
app.UseHsts();
app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(...);               // exceptions can occur here

Because UseExceptionHandler is registered near the top, it wraps everything that comes after it (routing, auth, endpoint execution, etc.) in a try/catch. When any of those downstream components throw, the exception bubbles back up through the call stack and lands inside the exception-handling middleware’s catch block.

If you register UseExceptionHandler after other middleware — say, after UseRouting or UseEndpoints — then:

• Any exception thrown by middleware before it (routing, auth, custom middleware, etc.) will never reach it, because the exception handler isn’t wrapping those components.
• The exception would instead propagate all the way up to the server (Kestrel) or the built-in developer exception page (if enabled), resulting in an unhandled 500 error with no custom error page/logging — defeating the purpose of having centralized error handling.

Routing Interview Questions

Routing is one of the highest-yield topics interviewers probe because it sits at the intersection of “how does a request become a method call” — a question that tests whether you understand the framework’s core mechanics rather than just memorized syntax. Here’s how to think about its importance and what’s commonly asked.

Why it’s a big deal conceptually:

Routing is the mechanism that maps an incoming URL + HTTP method to a specific piece of executable code (an endpoint — typically a controller action or minimal API delegate). Without it, the framework has no way of knowing what code should handle GET /api/products/5 vs POST /api/products. It’s the bridge between the raw HTTP request and your application logic.

Interviewers care about it because:

• It reveals whether you understand the request pipeline as a whole (routing is a middleware itself — UseRouting()/UseEndpoints() or the newer minimal hosting model).
• It’s where real-world bugs happen — ambiguous routes, wrong HTTP verb handling, route ordering issues, constraint mismatches.
• It connects to API design — RESTful conventions, versioning, attribute vs conventional routing.

23. What is routing in ASP.NET Core ? What is attribute routing ? What is conventional routing ?

Routing is the mechanism that matches an incoming HTTP request to an executable endpoint (a controller action, Razor Page, or minimal API delegate) based on the request’s URL and HTTP method, and extracts route values (like IDs) from the URL to make them available to that endpoint.

In other words: when a request comes in like GET /products/5, routing is what decides which method in your code should handle it, and it also extracts 5 as a value (e.g., id = 5) that gets passed into that method.

routing is implemented as endpoint routing, split into two middleware calls:

app.UseRouting();      // matches the request to an endpoint
// ... other middleware (auth, etc.) can inspect the matched endpoint here ...
app.UseEndpoints(endpoints =>
{
    endpoints.MapControllers(); // executes the matched endpoint
});

In minimal hosting, this is often implicit — you just call things like app.MapGet(…) or app.MapControllers() directly, and the framework wires up routing/endpoints for you.

There are two ways to define routes: conventional routing and attribute routing.

Conventional Routing

Conventional routing defines route patterns centrally, usually once, and lets those patterns apply broadly across controllers based on naming conventions (controller name, action name).

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

How it works:

• The URL is matched against the pattern’s placeholders: {controller}, {action}, {id}. {controller=Home} and {action=Index} provide default values — if the URL segment is missing, it defaults to Home/Index.
• {id?} marks id as optional.
• So /Products/Details/5 maps to ProductsController.Details(int id) with id = 5. A request to just / maps to HomeController.Index() via the defaults.

Characteristics:

• One central place to define URL structure/shape for a whole app.
• Relies on a consistent naming convention across controllers — if you deviate, the “convention” breaks down and you need attribute routing anyway.
• More common in traditional MVC apps (server-rendered views) with predictable, uniform URL patterns.
• Less precise control per-action — harder to express things like versioned APIs or unconventional URL shapes cleanly.

Attribute Routing

Attribute routing defines routes directly on controllers and actions using attributes, giving fine-grained, explicit control over each endpoint’s URL.

[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet]                  // GET api/products
    public IActionResult GetAll() { ... }

    [HttpGet("{id:int}")]      // GET api/products/5
    public IActionResult Get(int id) { ... }

    [HttpPost]                 // POST api/products
    public IActionResult Create(Product product) { ... }
}

How it works:

• [Route(“api/[controller]”)] on the class sets a base template; [controller] is a token that resolves to the controller’s name (Products).
• [HttpGet], [HttpPost], [HttpPut], [HttpDelete] attributes on individual actions both specify the HTTP verb and can append to/override the route template.
• Route constraints ({id:int}), optional segments, and custom templates can be set per-action with full precision.

Characteristics:

• Explicit and self-documenting — you can see the exact route right next to the action that handles it.
• Standard for Web APIs, since REST conventions often need precise control (e.g., GET /api/products/{id} vs GET /api/products/{id}/reviews).
• Doesn’t rely on naming convention magic — each route is declared exactly as intended.
• Easier to manage in large APIs with many endpoints that don’t follow a single uniform pattern.

24. What is the difference between [Route], [HttpGet], [HttpPost], etc ?

[Route] defines the URL pattern/template that maps to an action or controller. It doesn’t say anything about which HTTP verb (GET, POST, etc.) is allowed — it just sets up the path.

[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [Route("{id}")]
    public IActionResult GetById(int id) { ... }
}

By default, [Route] alone (without an HTTP verb attribute) responds to any HTTP method unless you explicitly restrict it.

[HttpGet], [HttpPost], [HttpPut], [HttpDelete], [HttpPatch]

These are HTTP verb attributes — they restrict an action to a specific HTTP method, and they can also optionally carry a route template.

[HttpGet]
public IActionResult GetAll() { ... }

[HttpGet("{id}")]
public IActionResult GetById(int id) { ... }

[HttpPost]
public IActionResult Create([FromBody] Product product) { ... }

Key Differences:

How they typically combine:

[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet]                     // GET api/products
    public IActionResult GetAll() { ... }

    [HttpGet("{id}")]             // GET api/products/5
    public IActionResult GetById(int id) { ... }

    [HttpPost]                    // POST api/products
    public IActionResult Create([FromBody] Product p) { ... }

    [HttpPut("{id}")]             // PUT api/products/5
    public IActionResult Update(int id, [FromBody] Product p) { ... }

    [HttpDelete("{id}")]          // DELETE api/products/5
    public IActionResult Delete(int id) { ... }
}

• [Route] on the controller sets the base path (api/products).
• Each [Http*] attribute appends its own segment and locks the action to that verb.

Why not just use [Route] everywhere? You could write:

[Route("api/products")]
[AcceptVerbs("GET")]
public IActionResult GetAll() { ... }

But [HttpGet], [HttpPost], etc. are more concise, self-documenting, and are the idiomatic convention in ASP.NET Core Web API — they make it immediately clear (to readers and to Swagger/OpenAPI tooling) what verb an action responds to.

25. What are route constraints ? Explain {id:int}. How do you create a custom route constraint ?

Route constraints restrict whether a route matches based on the value of a route parameter — not just its presence, but its type, format, or range. They act as a filter so a URL segment is only accepted if it satisfies a rule.

Without a constraint, {id} matches any string:

GET api/products/5       ✅ matches
GET api/products/abc     ✅ also matches (id = "abc")

With a constraint, you can force “id” to be numeric only, so “abc” won’t match that route at all — it’ll either 404 or fall through to another matching route/action.

Syntax:

Constraints are applied using a colon after the parameter name:

{parameterName:constraint}

Common Built-in Constraints:

Example:

[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    // Matches only if id is an integer
    [HttpGet("{id:int}")]
    public IActionResult GetById(int id) { ... }

    // Matches only if id is a GUID
    [HttpGet("{id:guid}")]
    public IActionResult GetByGuid(Guid id) { ... }

    // Combine multiple constraints
    [HttpGet("{id:int:min(1)}")]
    public IActionResult GetPositive(int id) { ... }
}

Optional parameters with constraints:

You can combine a constraint with ? to make it optional:

[HttpGet("{id:int?}")]
public IActionResult Get(int? id) { ... }

{id:int} Explained

{id:int} is a route parameter named id constrained to match only integer values — if the URL segment can’t be parsed as an int, the route doesn’t match, which helps with routing disambiguation and early filtering before the action even executes.

Creating a Custom Route Constraint in ASP.NET Core

To create a custom route constraint, you implement the IRouteConstraint interface and register it in the routing options. This lets you define matching logic beyond the built-in constraints (int, guid, alpha, etc.).

Step 1: Implement IRouteConstraint:

public class EvenNumberConstraint : IRouteConstraint
{
    public bool Match(
        HttpContext httpContext,
        IRouter route,
        string routeKey,
        RouteValueDictionary values,
        RouteDirection routeDirection)
    {
        if (values.TryGetValue(routeKey, out var value) && value != null)
        {
            if (int.TryParse(value.ToString(), out int number))
            {
                return number % 2 == 0;
            }
        }
        return false;
    }
}

Key points about the Match method:

• Returns true if the value satisfies the constraint (route matches), false otherwise.
• routeKey is the parameter name (e.g., “id”). values is the dictionary of route values for the current match attempt.
• routeDirection tells you whether this is being evaluated for an incoming request (IncomingRequest) or for URL generation (UrlGeneration) — useful if constraint logic should differ.

Step 2: Register the constraint

In Program.cs:

builder.Services.Configure<RouteOptions>(options =>
{
    options.ConstraintMap.Add("even", typeof(EvenNumberConstraint));
});

This maps the string key “even” to your constraint class — that key is what you’ll use in route templates.

Step 3: Use it in a route

[HttpGet("{id:even}")]
public IActionResult GetEven(int id)
{
    return Ok($"{id} is even");
}

GET /api/products/4	✅ Yes
GET /api/products/5	❌ No (odd)
GET /api/products/abc	❌ No (not even a number)

Important considerations:

• Constraints run on every routing attempt — keep the logic fast and lightweight. Avoid database calls or expensive operations inside Match.
• Constraints affect routing, not validation — a failed match usually results in a 404 (or falls through to another matching route), not a meaningful validation error. Don’t use custom constraints as a substitute for model validation.
• Constraints can be chained — e.g. {id:int:even} if you want to combine built-in and custom constraints.
• Alternative approach: IActionConstraint — if what you actually need is to select between overloaded actions (rather than restrict URL matching), IActionConstraint may be more appropriate; it’s evaluated later in the pipeline, after routing has matched a template, and can be closer to per-action selection logic.

26. What is route grouping ? What is MapGroup() in Minimal APIs ? How can you apply authorization to an entire route group ?

Route grouping lets you organize a set of related endpoints under a common prefix and shared configuration (metadata, filters, authorization, etc.) — instead of repeating the same settings on every single endpoint.

It’s the Minimal API equivalent of what [Route(“api/[controller]”)] + controller-level attributes give you in MVC/Web API — a way to apply cross-cutting concerns (prefix, auth, filters, tags, versioning) once, at the group level, rather than per-endpoint.

MapGroup()

MapGroup() is the method (introduced in .NET 7) used to create a route group in Minimal APIs. It returns a RouteGroupBuilder, which itself implements IEndpointRouteBuilder — so you can chain .MapGet(), .MapPost(), etc. on it just like you would on the app directly, and any group-level configuration cascades down to all endpoints in the group.

var app = builder.Build();

var products = app.MapGroup("api/products");

products.MapGet("/", GetAllProducts);
products.MapGet("/{id:int}", GetProductById);
products.MapPost("/", CreateProduct);
products.MapPut("/{id:int}", UpdateProduct);
products.MapDelete("/{id:int}", DeleteProduct);

app.Run();

Here, every endpoint automatically gets the api/products prefix:

• GET api/products/
• GET api/products/{id}
• POST api/products/

Why use it (benefits):

1. Shared prefix — avoid repeating "api/products/..." on every Map* call.
2. Shared metadata/filters — apply .WithTags(), .WithOpenApi(), .AddEndpointFilter(), .RequireAuthorization(), .RequireCors(), .RequireRateLimiting(), etc. once on the group, and it applies to all endpoints inside it.
3. Nested groups — groups can be nested for hierarchical organization:

   var api = app.MapGroup("api");
   var v1 = api.MapGroup("v1");
   var products = v1.MapGroup("products"); // final prefix: api/v1/products

4. Cleaner Program.cs — especially useful for organizing large Minimal API apps without needing full MVC controllers.
5. Can be extracted into extension methods for modular endpoint registration (a common pattern replacing “one giant Program.cs”).

Applying Authorization to an Entire Route Group

Use .RequireAuthorization() on the group returned by MapGroup() — it cascades to every endpoint registered on that group.

var products = app.MapGroup("api/products")
                   .RequireAuthorization(); // applies to ALL endpoints below

products.MapGet("/", GetAllProducts);
products.MapPost("/", CreateProduct);   // also requires auth
products.MapDelete("/{id:int}", DeleteProduct); // also requires auth

You can also target a specific policy or role:

var admin = app.MapGroup("api/admin")
                .RequireAuthorization("AdminOnly"); // named policy

var orders = app.MapGroup("api/orders")
                 .RequireAuthorization(policy => policy.RequireRole("Manager"));

Overriding at the endpoint level:

Metadata applied at the group level can be overridden per-endpoint if needed. For example, to make one endpoint in an otherwise-protected group public:

var products = app.MapGroup("api/products")
                   .RequireAuthorization();

products.MapGet("/", GetAllProducts);

products.MapGet("/public-info", GetPublicInfo)
        .AllowAnonymous(); // overrides the group's RequireAuthorization

This works because endpoint metadata is combined/overridden based on specificity — more specific (endpoint-level) metadata takes precedence over group-level metadata.

ASP.NET Core Web API Interview Questions

Why prepare specifically around ASP.NET Core Web API interview questions:

It’s usually the actual job, not a formality – For most .NET backend roles, Web API work is the day-to-day — building endpoints, wiring up auth, handling data access, structuring services. Interviewers ask these questions because they map almost 1:1 to what you’ll be doing in week one, unlike, say, algorithmic trivia that rarely shows up in daily work.

It’s a fast way to filter “used it” from “understands it” – Web API has enough moving parts (routing, model binding, filters, middleware, DI, auth) that surface-level familiarity breaks down quickly under follow-up questions. A structured interview on this topic lets an interviewer distinguish, in 20–30 minutes, someone who’s copy-pasted from tutorials from someone who’s actually debugged production issues.

It reveals whether you understand the pipeline, not just isolated features – Almost every ASP.NET Core interview thread (like the one we just went through) is designed to walk you from a narrow starting point ([Route] vs [HttpGet]) into the broader request lifecycle. Preparing deliberately means you’re not just memorizing 50 disconnected facts — you’re building a mental model of how a request flows from routing → model binding → filters → action → response. That mental model is reusable and lets you improvise on questions you’ve never seen before.

Depth matters more than breadth at senior levels – Junior interviews often stop at “what is X.” Mid/senior interviews probe trade-offs and failure modes — e.g., “constraints don’t validate, they just affect matching, so a mismatch gives you a 404 not a helpful error.” If you haven’t prepared with that framing in mind, you’ll answer correctly but sound junior anyway.

Practical outcome: it directly affects your interview performance – Concretely, structured prep helps you:

• Answer confidently without long pauses (fluency signals real experience)
• Anticipate the natural follow-up question (interviewers often chain, like we did: [Route] → constraints → custom constraints → groups)
• Avoid contradicting yourself when asked “why not just do X instead” (a very common interview technique)
• Talk about real-world gotchas unprompted, which is the strongest signal of hands-on experience

27. What is ASP.NET Core Web API ? What is the difference between MVC and Web API ?

ASP.NET Core Web API is a framework built on top of ASP.NET Core for building HTTP-based services (RESTful APIs) that can be consumed by a wide range of clients — browsers, mobile apps, desktop apps, IoT devices, or other servers. Instead of returning HTML views, it returns data — typically in JSON (or XML) — over HTTP.

Key points to mention in an interview:

• It’s cross-platform (runs on Windows, Linux, macOS) since it’s built on .NET Core. It’s designed around HTTP verbs — GET, POST, PUT, DELETE, PATCH — mapped to CRUD operations.
• Controllers typically inherit from ControllerBase (not Controller), since they don’t need view-rendering capabilities.
• It supports content negotiation (returning JSON or XML based on the Accept header), model binding, model validation, filters, middleware, dependency injection, etc. — same underlying pipeline as ASP.NET Core MVC.
• In modern ASP.NET Core (post 3.0), MVC and Web API have been unified into a single framework — there’s no separate “Web API” package anymore. You just build a Web API project using the same Microsoft.AspNetCore.Mvc namespace.

Example minimal controller:

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet]
    public IActionResult GetAll() => Ok(products);

    [HttpGet("{id}")]
    public IActionResult GetById(int id) => Ok(product);

    [HttpPost]
    public IActionResult Create(Product product) => CreatedAtAction(...);
}

Difference between MVC and Web API

This is a bit of a “trick” interview question in the ASP.NET Core world, because historically (in classic ASP.NET / pre-Core), MVC and Web API were separate frameworks. In ASP.NET Core, they’ve been merged into one framework (ASP.NET Core MVC), so technically there is no separate “Web API framework” anymore — it’s all part of the same pipeline.

That said, interviewers usually want you to explain the conceptual difference in purpose/usage:

28. What is ControllerBase ? What is the difference between Controller and ControllerBase ? What does [ApiController] do ?

ControllerBase is the base class for building API controllers in ASP.NET Core. It lives in the Microsoft.AspNetCore.Mvc namespace and provides all the core functionality needed to handle HTTP requests and produce responses — without any support for rendering views (HTML).

It gives you access to things like:

• HttpContext, Request, Response
• ModelState (for validation)
• Helper methods for building responses: Ok(), NotFound(), BadRequest(), CreatedAtAction(), NoContent(), StatusCode(), etc.
• User (for accessing the authenticated user/claims)
• Url (IUrlHelper for generating links)

Example:

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet("{id}")]
    public IActionResult GetById(int id)
    {
        var product = _repo.Find(id);
        if (product == null)
            return NotFound();

        return Ok(product);
    }
}

Difference between Controller and ControllerBase

Controller inherits from ControllerBase and adds view-related functionality on top of it.

What does [ApiController] do ?

[ApiController] is an attribute you put on a controller class to opt into a set of API-specific conventions and behaviors that make building REST APIs easier and more consistent. It’s typically combined with ControllerBase.

Specifically, it enables:

a. Automatic HTTP 400 responses on model validation errors

• If ModelState.IsValid is false, the framework automatically returns a 400 Bad Request with a ProblemDetails response — you don’t need to manually check ModelState.IsValid in every action.

b. Attribute routing requirement

• Forces the use of attribute-based routing ([Route], [HttpGet], etc.) instead of conventional routing — makes route definitions explicit and required.

c. Binding source parameter inference

• Automatically infers where action parameters come from ([FromBody], [FromRoute], [FromQuery]) based on parameter type/complexity, so you often don’t need to specify them manually.
• Example: complex types default to [FromBody], simple types default to [FromQuery]/[FromRoute].

d. Multipart/form-data inference for IFormFile parameters

• Automatically recognizes file upload parameters.

e. Problem details for error responses

• Standardizes error responses using the ProblemDetails format (RFC 7807), improving API consistency.

29. What happens when model validation fails with [ApiController] ?

When a controller is decorated with [ApiController], ASP.NET Core automatically handles invalid model state for you — you don’t need to write if (!ModelState.IsValid) return BadRequest(ModelState); manually in every action.

What happens under the hood:

• Model binding runs first (mapping request data — body, route, query — to your action parameters/model).
• If binding produces validation errors (e.g., a required field is missing, a data annotation like [Required], [Range], [StringLength] fails), the framework sets ModelState.IsValid = false.
• Before your action method even executes, a built-in filter — ModelStateInvalidFilter — runs as part of the action-invocation pipeline and short-circuits the request.
• It automatically returns an HTTP 400 Bad Request response, formatted as a ValidationProblemDetails object (an extension of ProblemDetails, per RFC 7807), containing the validation errors.

Example:

public class ProductDto
{
    [Required]
    public string Name { get; set; }

    [Range(1, 1000)]
    public decimal Price { get; set; }
}

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpPost]
    public IActionResult Create(ProductDto product)
    {
        // This code is NEVER reached if validation fails —
        // the [ApiController] filter already returned 400.
        return Ok(product);
    }
}

If you POST { “Price”: 5000 } (missing Name, invalid Price), the response is automatically:

{
  "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
    "Name": ["The Name field is required."],
    "Price": ["The field Price must be between 1 and 1000."]
  },
  "traceId": "00-abc123..."
}

• This automatic behavior is only enabled because of [ApiController] — without it, ModelState.IsValid stays your responsibility to check manually.
• The action method body never executes when validation fails — it’s short-circuited earlier in the pipeline.
• The response format follows RFC 7807 (Problem Details for HTTP APIs), giving a consistent, machine-readable error structure across your whole API.
• You can customize this behavior by configuring ApiBehaviorOptions.InvalidModelStateResponseFactory in Program.cs/Startup.cs:

  builder.Services.Configure<ApiBehaviorOptions>(options =>
  {
      options.InvalidModelStateResponseFactory = context =>
      {
          // custom response logic
          return new BadRequestObjectResult(context.ModelState);
      };
  });

30. What are FromBody, FromRoute, FromQuery, and FromHeader ?

These attributes tell ASP.NET Core where in the HTTP request to look for a value when binding it to an action method’s parameter or model property. This process is called model binding.

[FromRoute]

Binds a parameter from the route/URL segment (values captured by the route template).

[HttpGet("{id}")]
public IActionResult GetById([FromRoute] int id)
{
    // URL: GET /api/products/5  → id = 5
}

[FromQuery]

Binds a parameter from the query string.

[HttpGet]
public IActionResult Search([FromQuery] string name, [FromQuery] int page)
{
    // URL: GET /api/products?name=phone&page=2
}

[FromBody]

Binds a parameter from the request body (typically JSON), deserialized into a complex object. Only one parameter per action can use [FromBody].

[HttpPost]
public IActionResult Create([FromBody] Product product)
{
    // Body: { "name": "Phone", "price": 500 }
}

[FromHeader]

Binds a parameter from an HTTP request header.

[HttpGet]
public IActionResult Get([FromHeader(Name = "X-Api-Key")] string apiKey)
{
    // Reads the "X-Api-Key" header value
}

Summary Table:

Do you need to specify them explicitly?

With [ApiController], ASP.NET Core does automatic binding source inference, so in many common cases you don’t need to write the attribute explicitly:

• Complex types (classes) → inferred as [FromBody]
• Simple types (int, string, Guid, etc.) that match a route parameter name → inferred as [FromRoute]
• Simple types that don’t match a route parameter → inferred as [FromQuery]
• IFormFile / IFormFileCollection → inferred as [FromForm]

You still need to specify [FromHeader] explicitly — it’s never inferred automatically.

31. What is the difference between Ok(), Created(), CreatedAtAction(), BadRequest(), NotFound(), and NoContent() ?

These are all helper methods available in ControllerBase (and Controller) that return IActionResult types, each mapping to a specific HTTP status code. Using them makes your API responses explicit and RESTful, rather than manually setting status codes everywhere.

Ok() → 200 OK

Indicates the request succeeded. Optionally returns data in the response body.

[HttpGet("{id}")]
public IActionResult GetById(int id)
{
    var product = _repo.Find(id);
    return Ok(product); // 200 + product in body
}

Created() → 201 Created

Indicates a new resource was successfully created. Requires you to manually provide the URI of the new resource plus the resource itself.

[HttpPost]
public IActionResult Create(Product product)
{
    _repo.Add(product);
    string uri = $"/api/products/{product.Id}";
    return Created(uri, product); // 201 + Location header + body
}

CreatedAtAction() → 201 Created

Same as Created(), but instead of manually building the URI string, you point to an action method (and route values), and the framework generates the correct URL for the Location header using routing.

[HttpPost]
public IActionResult Create(Product product)
{
    _repo.Add(product);
    return CreatedAtAction(nameof(GetById), new { id = product.Id }, product);
    // 201 + Location: /api/products/{id} (auto-generated via route)
}

BadRequest() → 400 Bad Request

Indicates the client sent an invalid request (e.g., failed validation, bad input).

[HttpPost]
public IActionResult Create(Product product)
{
    if (product.Price <= 0)
        return BadRequest("Price must be greater than zero.");

    ...
}

NotFound() → 404 Not Found

Indicates the requested resource doesn’t exist.

[HttpGet("{id}")]
public IActionResult GetById(int id)
{
    var product = _repo.Find(id);
    if (product == null)
        return NotFound(); // 404

    return Ok(product);
}

NoContent() → 204 No Content

Indicates the request succeeded, but there’s no data to return in the response body — common for PUT/DELETE operations.

[HttpDelete("{id}")]
public IActionResult Delete(int id)
{
    var product = _repo.Find(id);
    if (product == null)
        return NotFound();

    _repo.Remove(product);
    return NoContent(); // 204, empty body
}

Summary Table:

32. What is content negotiation ?

Content negotiation is the mechanism by which a Web API decides what format to send the response back in (e.g., JSON, XML, plain text), based on what the client says it can accept, rather than the server always returning a fixed format.

It works using the standard HTTP Accept request header, and the corresponding Content-Type response header.

How it works:

1. The client sends a request with an Accept header specifying the format(s) it wants:

   GET /api/products/1
   Accept: application/json

2. ASP.NET Core’s content negotiation system looks at the registered output formatters and picks the one matching the requested media type.
3. The response is serialized accordingly, and the Content-Type header reflects the chosen format:

   Content-Type: application/json

If the client instead sends:

Accept: application/xml

…and XML formatters are configured, the same endpoint returns XML instead — without changing any controller code.

Example:

[HttpGet("{id}")]
public IActionResult GetById(int id)
{
    var product = _repo.Find(id);
    return Ok(product); // format decided by content negotiation
}

• Request with Accept: application/json → response body: {"id":1,"name":"Phone"}
• Request with Accept: application/xml → response body: <Product><Id>1</Id><Name>Phone</Name></Product> (if XML formatter is added)

Default behavior in ASP.NET Core:

• JSON is the default output formatter (System.Text.Json since ASP.NET Core 3.0, previously Newtonsoft.Json).
• XML is NOT included by default — you must explicitly add it:

  builder.Services.AddControllers()
      .AddXmlSerializerFormatters();

• If the Accept header requests a format the server doesn’t support, ASP.NET Core by default ignores the header and returns the default formatter’s output (JSON) rather than a 406 Not Acceptable — unless you explicitly enable strict negotiation:

  builder.Services.AddControllers(options =>
  {
      options.ReturnHttpNotAcceptable = true; // returns 406 if format unsupported
  });

Input vs Output formatters:

Content negotiation usually refers to output (response), but there’s a related concept for input:

• Output formatters — serialize the response based on Accept header.
• Input formatters — deserialize the incoming request body based on Content-Type header (e.g., telling the server the request body is JSON).

33. Explain IActionResult and ActionResult<T>

Both are return types used in Web API action methods to represent an HTTP response, but they differ in flexibility, type-safety, and how well they play with Swagger/OpenAPI documentation.

IActionResult

An interface representing any action result. It’s the common return type shared by all the helper methods (Ok(), NotFound(), BadRequest(), NoContent(), etc.), since they all return classes implementing IActionResult (OkObjectResult, NotFoundResult, etc.).

[HttpGet("{id}")]
public IActionResult GetById(int id)
{
    var product = _repo.Find(id);
    if (product == null)
        return NotFound();       // NotFoundResult

    return Ok(product);          // OkObjectResult
}

Characteristics:

• Flexible — lets you return any combination of result types (Ok, NotFound, BadRequest, etc.) from the same method.
• Not strongly typed — the compiler doesn’t know what the actual success payload type is; tools like Swagger can’t automatically infer the response model unless you add [ProducesResponseType(typeof(Product), 200)] manually.

ActionResult<T>

A generic class introduced in ASP.NET Core 2.1 that combines the flexibility of IActionResult with strong typing of the actual data being returned. It supports implicit conversion from both your data type T and standard action results.

[HttpGet("{id}")]
public ActionResult<Product> GetById(int id)
{
    var product = _repo.Find(id);
    if (product == null)
        return NotFound();       // implicit conversion to ActionResult<Product>

    return product;              // implicit conversion, wraps in Ok(product) automatically
    // return Ok(product);       // also valid
}

Characteristics:

• Strongly typed — the method signature tells you (and tooling) exactly what successful responses look like: Product.
• Better Swagger/OpenAPI integration — since the return type is known, tools can automatically generate accurate response schemas without needing extra [ProducesResponseType] attributes.
• Still supports returning other status results (NotFound(), BadRequest(), etc.) via implicit conversion — you don’t lose flexibility.
• You can return T directly (e.g., return product;) and it automatically becomes a 200 OK with that body.

Summary Table:

34. What HTTP status code should be returned after successfully creating a resource ?

201 Created is the correct status code after successfully creating a new resource via a POST request.

Why 201, not 200?

In ASP.NET Core, use CreatedAtAction() (preferred) or Created():

• 200 OK means “the request succeeded” — generic, doesn’t say anything about a new resource being created.
• 201 Created specifically means “a new resource was created as a result of this request,” and per HTTP spec, the response should ideally include:
  • A Location header pointing to the URI of the newly created resource.
  • Optionally, the created resource itself in the response body.

[HttpPost]
public IActionResult Create(Product product)
{
    _repo.Add(product);

    return CreatedAtAction(nameof(GetById), new { id = product.Id }, product);
    // Status: 201 Created
    // Location: /api/products/{id}
    // Body: the created product
}

Response headers/body look like:

HTTP/1.1 201 Created
Location: /api/products/5
Content-Type: application/json

{ "id": 5, "name": "Phone", "price": 500 }

Common mistake in interviews:

Returning Ok(product) (200) after a POST — it works, but it’s not RESTfully correct. Interviewers often ask this specifically to check if you know the difference between “successful operation” (200) vs “resource created” (201) semantics.

35. What is the difference between PUT and PATCH ? How do you implement PATCH in ASP.NET Core ?

Both are HTTP verbs used to update an existing resource, but they differ in scope of the update.

Example scenario – Given a resource:

{ "id": 1, "name": "Phone", "price": 500, "stock": 20 }

PUT request body (must send the whole object):

{ "id": 1, "name": "Phone", "price": 600, "stock": 20 }

If you forgot to include stock, it might get reset to 0/null — because PUT expects the complete resource.

PATCH request body (only what changes):

{ "price": 600 }

Only price is updated; name and stock remain untouched..

Implementing PUT in ASP.NET Core (for comparison)

[HttpPut("{id}")]
public IActionResult Update(int id, Product updatedProduct)
{
    var product = _repo.Find(id);
    if (product == null) return NotFound();

    product.Name = updatedProduct.Name;
    product.Price = updatedProduct.Price;
    product.Stock = updatedProduct.Stock;

    return NoContent(); // 204
}

Implementing PATCH in ASP.NET Core

There are two common approaches:

Approach 1: JSON Patch (RFC 6902) — the “standard” way:

Uses Microsoft.AspNetCore.JsonPatch with a JsonPatchDocument<T>. The client sends a series of operations (add, replace, remove) rather than raw field values.

Setup:

dotnet add package Microsoft.AspNetCore.Mvc.NewtonsoftJson

builder.Services.AddControllers().AddNewtonsoftJson();

Controller:

[HttpPatch("{id}")]
public IActionResult Patch(int id, [FromBody] JsonPatchDocument<Product> patchDoc)
{
    if (patchDoc == null) return BadRequest();

    var product = _repo.Find(id);
    if (product == null) return NotFound();

    patchDoc.ApplyTo(product, ModelState);

    if (!ModelState.IsValid)
        return BadRequest(ModelState);

    return NoContent();
}

Client request body (JSON Patch format):

[
  { "op": "replace", "path": "/price", "value": 600 }
]

• op — the operation: replace, add, remove, copy, move, test
• path — which property to modify
• value — the new value

Approach 2: Simple DTO-based partial update (more common in practice)

Instead of the formal JSON Patch spec, many real-world APIs just accept a partial DTO where only provided fields are updated (often using nullable properties to distinguish “not provided” from “set to default”).

public class ProductPatchDto
{
    public string? Name { get; set; }
    public decimal? Price { get; set; }
    public int? Stock { get; set; }
}

[HttpPatch("{id}")]
public IActionResult Patch(int id, ProductPatchDto dto)
{
    var product = _repo.Find(id);
    if (product == null) return NotFound();

    if (dto.Name != null) product.Name = dto.Name;
    if (dto.Price.HasValue) product.Price = dto.Price.Value;
    if (dto.Stock.HasValue) product.Stock = dto.Stock.Value;

    return NoContent();
}

This approach is simpler to consume from typical frontend clients (just send changed fields as plain JSON) but doesn’t follow the formal JSON Patch RFC.

36. What is JSON Patch ?

JSON Patch is a standardized format (defined in RFC 6902) for describing partial modifications to a JSON document. Instead of sending the entire updated resource, the client sends a list of operations that describe exactly what should change — making it ideal for implementing HTTP PATCH requests.

Structure:

A JSON Patch document is a JSON array of operation objects. Each operation has:

• op — the operation type: add, remove, replace, move, copy, or test
• path — a JSON Pointer (RFC 6901) indicating which part of the document to target
• value — the new value (required for add, replace, test; not used for remove)

[
  { "op": "replace", "path": "/price", "value": 600 },
  { "op": "add", "path": "/tags/-", "value": "new-arrival" },
  { "op": "remove", "path": "/discontinued" }
]

The six operations:

Example in context – Given this resource:

{ "id": 1, "name": "Phone", "price": 500, "stock": 20 }

This JSON Patch request:

[
  { "op": "replace", "path": "/price", "value": 600 },
  { "op": "replace", "path": "/stock", "value": 25 }
]

…results in:

{ "id": 1, "name": "Phone", "price": 600, "stock": 25 }

Only the specified fields change — everything else stays as-is.

JSON Patch in ASP.NET Core

ASP.NET Core supports JSON Patch through the Microsoft.AspNetCore.JsonPatch package and the JsonPatchDocument<T> type:

[HttpPatch("{id}")]
public IActionResult Patch(int id, [FromBody] JsonPatchDocument<Product> patchDoc)
{
    var product = _repo.Find(id);
    if (product == null) return NotFound();

    patchDoc.ApplyTo(product, ModelState);

    if (!ModelState.IsValid)
        return BadRequest(ModelState);

    return NoContent();
}

ApplyTo() executes each operation from the patch document against the target object.

JSON Patch vs. Simple Partial DTO

37. How do you return XML from an ASP.NET Core Web API and how do you consume XML in an ASP.NET Core API ? How do you implement global API exception handling ?

By default, ASP.NET Core Web API only supports JSON. To support XML, you register XML formatters via AddXmlSerializerFormatters() (or AddXmlDataContractSerializerFormatters() for more complex types) in Program.cs. Once registered, it works both ways: for output, content negotiation returns XML when the client sends Accept: application/xml; for input, the framework deserializes the request body into your model when Content-Type: application/xml is set — all without changing any controller code, since the formatter selection happens transparently based on HTTP headers.

Global API Exception Handling in ASP.NET Core

Instead of try/catch in every action, ASP.NET Core supports centralized exception handling. The classic approach is app.UseExceptionHandler() middleware, which catches unhandled exceptions from the whole pipeline and returns a ProblemDetails response. Since .NET 8, the recommended approach is implementing IExceptionHandler — a DI-friendly abstraction where you can register multiple handlers that run in order. For custom exception-to-status-code mapping — like a NotFoundException becoming 404 — I’d write custom middleware or an IExceptionHandler that inspects the exception type. Exception filters (IExceptionFilter) are an older, MVC-only alternative that won’t catch exceptions outside the MVC pipeline, so middleware-based approaches are generally preferred.

Minimal APIs Interview Questions

ASP.NET CORE Minimal APIs matter in interviews because they’re now the default template in modern .NET, they’re heavily used in microservices and cloud-native architectures, and they test whether a candidate understands the underlying ASP.NET Core pipeline rather than relying purely on MVC conventions. Being asked about them is really a proxy for: ‘Is this candidate’s knowledge current, and do they understand trade-offs between lightweight and full MVC-based APIs?

Here’s why interviewers increasingly focus on Minimal APIs and why you need to be prepared:

a. Minimal APIs are now the default template in .NET

• Since .NET 6+, dotnet new webapi generates a Minimal API project by default (not a controller-based one).
• Any interviewer working with modern .NET codebases (.NET 6/7/8/9) will likely be using or evaluating Minimal APIs in real projects — so it’s now considered baseline knowledge, not a niche topic.

b. It tests whether your knowledge is current or outdated

• Many candidates learned ASP.NET Core only through Controller-based Web API (older tutorials, older jobs).
• Asking about Minimal APIs immediately reveals whether you’ve kept up with the framework’s evolution — a strong signal of whether you follow the ecosystem or are stuck on legacy patterns.

c. Companies are actively migrating toward it for microservices

• Minimal APIs are lightweight, have less boilerplate, and start faster — making them attractive for microservices, serverless functions, and containerized workloads (fewer resources, smaller footprint).
• If a company is building microservices or cloud-native systems, they specifically want engineers comfortable with this style.

d. It tests understanding of the underlying pipeline, not just syntax

• Minimal APIs strip away the MVC abstraction (controllers, filters, model binding conventions), forcing you to understand things more directly:
  • WebApplication / WebApplicationBuilder
  • Endpoint routing (app.MapGet, app.MapPost, etc.)
  • Middleware ordering
  • Dependency injection at the endpoint level
• Interviewers use it to test whether you understand the framework, rather than just memorized Controller patterns.

e. It reveals knowledge of trade-offs — a sign of seniority

• Knowing when to use Minimal APIs vs Controllers (e.g., simple CRUD/microservices vs large enterprise apps needing filters, model binding conventions, versioning, [ApiController] conventions) shows architectural judgment, not just syntax memorization — which is exactly what separates mid-level from senior candidates.

f. Performance-conscious teams specifically look for it

• Minimal APIs have less overhead than MVC controllers (no controller activation, fewer filters by default), which matters for teams optimizing for high-throughput APIs.
• Being able to discuss this shows you understand performance implications of architectural choices — a common senior-level interview theme.

g. It often comes packaged with other modern-era topics

• Once you know Minimal APIs, interviewers will likely chain into related modern .NET topics that are also now common:
  • IExceptionHandler (rather than filters)
  • Program.cs top-level statements (no Startup.cs)
  • Native AOT compilation support
  • Endpoint filters (AddEndpointFilter) instead of MVC filters
• These are all part of the same “modern .NET” cluster interviewers use to gauge how current your skills are.

h. It’s a quick way to differentiate candidates in a crowded market

• Since ASP.NET Core roles get a huge number of applicants, interviewers use Minimal API knowledge as a filter — it’s a low-effort way to separate candidates who only know “textbook MVC” from those with genuine hands-on modern experience.

38. What are Minimal APIs and how are Minimal APIs different from controller-based APIs ? When would you choose Minimal APIs over controllers?

Minimal APIs (introduced in .NET 6) let you build HTTP APIs with minimal ceremony — no controllers, no boilerplate, no attribute routing classes. You define routes and handlers directly against the WebApplication instance.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/products/{id}", (int id, IProductService svc) => svc.GetById(id));
app.MapPost("/products", (Product p, IProductService svc) => svc.Add(p));

app.Run();

That’s a complete, working API — no Program.cs split, no [ApiController], no separate controller file.

Key Differences from Controller-Based APIs

Notably, both ultimately run on the same underlying routing and hosting infrastructure (EndpointRouteBuilder) — Minimal APIs aren’t a separate framework, just a lighter-weight way to register endpoints.

When to Choose Minimal APIs vs Controllers

Choose Minimal APIs when:

• Building microservices or small, focused APIs with few endpoints.
• Building serverless functions or lightweight backends (e.g., Azure Functions-style workloads).
• where startup time and memory footprint matter.
• You want fast prototyping or simple CRUD endpoints without ceremony.
• The team is comfortable with a more functional/lambda-based style.
• You don’t need the full MVC filter pipeline or complex model binding conventions.

Choose Controllers when:

• Building large, complex APIs with many endpoints, where organizing by controller/resource keeps things maintainable.
• You need the full MVC feature set: model binding conventions, automatic validation via [ApiController], rich filter pipeline, versioning conventions, etc.
• The team is already experienced with MVC patterns and conventions.
• You need better built-in support for things like API versioning, conventions-based Swagger/OpenAPI generation, or complex content negotiation.

39. Explain what is MapGet(), MapPost() and MapGroup()

MapGet() and MapPost() are extension methods on IEndpointRouteBuilder (implemented by WebApplication) used to register Minimal API endpoints for specific HTTP verbs.

app.MapGet("/products", () => "Get all products");
app.MapPost("/products", (Product p) => "Product created");

• MapGet(pattern, handler) — registers an endpoint that responds to HTTP GET requests at the given route pattern.
• MapPost(pattern, handler) — registers an endpoint that responds to HTTP POST requests.

There are corresponding siblings too: MapPut(), MapDelete(), MapPatch(), and the generic MapMethods() (for custom/multiple verbs).

app.MapGet("/products/{id:int}", (int id, IProductService svc) =>
{
    var product = svc.GetById(id);
    return product is not null ? Results.Ok(product) : Results.NotFound();
})
.WithName("GetProductById")
.Produces<Product>(200)
.Produces(404);

• The route pattern can include route constraints ({id:int}), optional segments, etc.
• The handler delegate supports full dependency injection (parameters are resolved from DI, route values, query string, or body automatically based on type/binding rules).
• Both return an IEndpointConventionBuilder/RouteHandlerBuilder, letting you chain metadata: .WithName(), .WithTags(), .Produces(), .RequireAuthorization(), .AddEndpointFilter(), etc.

MapGroup()

Introduced in .NET 7, MapGroup() lets you group related endpoints under a common route prefix and apply shared configuration (filters, auth, metadata) to all of them at once — solving the “Minimal APIs get messy at scale” problem.

var products = app.MapGroup("/products")
                   .WithTags("Products")
                   .RequireAuthorization();

products.MapGet("/", () => "Get all products");
products.MapGet("/{id}", (int id) => $"Get product {id}");
products.MapPost("/", (Product p) => "Created");

This is equivalent to registering /products, /products/{id}, etc., but:

• The prefix (/products) is applied automatically to all routes in the group.
• Any .WithTags(), .RequireAuthorization(), .AddEndpointFilter(), .MapToApiVersion() etc. chained on the group cascades to every endpoint inside it — no need to repeat it per route.
• Groups can be nested (a group within a group) for further sub-organization.
• You can also extract group definitions into extension methods per feature/resource, giving you something like a “controller-lite” structure:

public static class ProductEndpoints
{
    public static void MapProductEndpoints(this IEndpointRouteBuilder app)
    {
        var group = app.MapGroup("/products").WithTags("Products");
        group.MapGet("/", GetAll);
        group.MapGet("/{id}", GetById);
        group.MapPost("/", Create);
    }
}

// Program.cs
app.MapProductEndpoints();

40. How do you apply authorization to Minimal API endpoints ?

In Minimal APIs, you apply authorization using the RequireAuthorization() extension method on the endpoint, instead of using [Authorize] attributes (which is how you do it in MVC controllers).

var app = builder.Build();

app.MapGet("/secure-data", () => "This is protected")
   .RequireAuthorization();

This requires the user to simply be authenticated (no specific policy).

Applying a specific policy:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("AdminOnly", policy =>
        policy.RequireRole("Admin"));
});

app.MapGet("/admin", () => "Admin area")
   .RequireAuthorization("AdminOnly");

Requiring specific roles or claims inline:

app.MapGet("/manager", () => "Manager data")
   .RequireAuthorization(policy => policy.RequireRole("Manager"));

Applying authorization to a group of endpoints:

Instead of chaining RequireAuthorization() on every route, you can group endpoints and apply it once:

var group = app.MapGroup("/api/orders")
                .RequireAuthorization();

group.MapGet("/", GetOrders);
group.MapPost("/", CreateOrder);

All endpoints inside that group inherit the authorization requirement.

Allowing anonymous access to specific endpoints in a protected group.

If a group is secured but one endpoint should be public:

group.MapGet("/public-info", GetPublicInfo)
     .AllowAnonymous();

Prerequisites:

For RequireAuthorization() to work, you still need the standard middleware pipeline set up:

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

And the authorization services registered:

builder.Services.AddAuthorization();

Key interview point to mention – The main conceptual shift from MVC is: authorization is applied fluently via extension methods on the endpoint (or route group) rather than declaratively via attributes on a controller/action. This fits the Minimal API philosophy of composing behavior through method chaining rather than decorating classes.

41. How do you inject a service into a Minimal API endpoint ? How do you perform validation in Minimal APIs?

Minimal APIs support parameter-based dependency injection — you simply add the service as a parameter to the route handler delegate, and the framework resolves it from the DI container automatically.

Basic Example:

builder.Services.AddScoped<IOrderService, OrderService>();

var app = builder.Build();

app.MapGet("/orders", (IOrderService orderService) =>
{
    return orderService.GetAllOrders();
});

No attributes are needed — the runtime inspects the parameter types and resolves them from the service container, similar to constructor injection in MVC controllers.

Explicit binding with [FromServices]:

Usually unnecessary since Minimal APIs infer services automatically, but you can be explicit (useful in ambiguous cases or with certain complex types):

app.MapGet("/orders", ([FromServices] IOrderService orderService) =>
{
    return orderService.GetAllOrders();
});

Mixing services with route/query parameters and request body:

app.MapPost("/orders/{customerId}", (
    int customerId,
    [FromBody] OrderDto order,
    IOrderService orderService,
    ILogger<Program> logger) =>
{
    logger.LogInformation("Creating order for {CustomerId}", customerId);
    return orderService.CreateOrder(customerId, order);
});

The framework figures out parameter sources using conventions: route values, query strings, body, services, etc.

Validation in Minimal APIs

Unlike MVC controllers, Minimal APIs do not have built-in automatic model validation (no automatic ModelState.IsValid behavior tied to [ApiController]). You have to handle validation explicitly.

app.MapPost("/orders", (OrderDto order) =>
{
    if (string.IsNullOrWhiteSpace(order.ProductName) || order.Quantity <= 0)
    {
        return Results.ValidationProblem(new Dictionary<string, string[]>
        {
            { "Quantity", new[] { "Quantity must be greater than zero." } }
        });
    }

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

We can also use Data Annotations manually:

public class OrderDto
{
    [Required]
    public string ProductName { get; set; }

    [Range(1, int.MaxValue)]
    public int Quantity { get; set; }
}

Since these aren’t auto-validated, you validate manually via Validator.TryValidateObject:

app.MapPost("/orders", (OrderDto order) =>
{
    var context = new ValidationContext(order);
    var results = new List<ValidationResult>();

    bool isValid = Validator.TryValidateObject(order, context, results, true);

    if (!isValid)
    {
        var errors = results.ToDictionary(
            r => r.MemberNames.FirstOrDefault() ?? "",
            r => new[] { r.ErrorMessage }
        );
        return Results.ValidationProblem(errors);
    }

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

42. How do you define common metadata for a group of endpoints ?

In Minimal APIs, you use MapGroup() to create a route group, and then chain metadata-related extension methods onto the group itself. Any metadata applied to the group is automatically inherited by every endpoint mapped within it.

Basic example:

var group = app.MapGroup("/api/orders")
                .WithTags("Orders")
                .RequireAuthorization()
                .WithOpenApi();

group.MapGet("/", GetOrders);
group.MapPost("/", CreateOrder);
group.MapDelete("/{id}", DeleteOrder);

Here, all three endpoints automatically get:

• The /api/orders prefix
• The “Orders” OpenAPI tag
• The authorization requirement
• OpenAPI metadata generation

Example combining several:

var group = app.MapGroup("/api/products")
    .RequireAuthorization("AdminOnly")
    .WithTags("Products")
    .AddEndpointFilter<ValidationFilter<ProductDto>>()
    .RequireRateLimiting("fixed")
    .WithOpenApi();

group.MapGet("/", GetProducts);
group.MapPost("/", CreateProduct);

Overriding metadata for a specific endpoint within the group:

Individual endpoints can still customize or override group-level settings:

group.MapGet("/public", GetPublicProducts)
     .AllowAnonymous();   // overrides the group's RequireAuthorization()

group.MapPost("/", CreateProduct)
     .WithTags("Products", "Write-Operations"); // adds additional tag

Nested groups:

Groups can also be nested, and metadata compounds down the hierarchy:

var api = app.MapGroup("/api");
var orders = api.MapGroup("/orders").RequireAuthorization();

orders.MapGet("/", GetOrders); // inherits /api/orders + RequireAuthorization

MapGroup() returns a RouteGroupBuilder, which implements the same IEndpointConventionBuilder interface as individual route mappings (MapGet, MapPost, etc.). That’s why all the same fluent extension methods (RequireAuthorization, WithTags, AddEndpointFilter, etc.) work identically whether applied to a single endpoint or an entire group — it’s a unified builder abstraction, not a special case for groups.

43. How do you return different HTTP status codes from a Minimal API ?

Minimal APIs use the static Results class (or the TypedResults class for a strongly-typed variant) to construct responses with specific HTTP status codes, instead of returning IActionResult types like in MVC controllers.

Common Results methods and their status codes:

Basic example:

app.MapGet("/orders/{id}", (int id, IOrderService service) =>
{
    var order = service.GetById(id);

    if (order is null)
        return Results.NotFound();

    return Results.Ok(order);
});

Returning different results based on logic:

app.MapPost("/orders", (OrderDto dto, IOrderService service) =>
{
    if (dto.Quantity <= 0)
        return Results.BadRequest("Quantity must be greater than zero.");

    var created = service.CreateOrder(dto);
    return Results.Created($"/orders/{created.Id}", created);
});

Using TypedResults (strongly-typed, better for OpenAPI + testability):

TypedResults is preferred in .NET 7+ because it improves OpenAPI schema generation and makes unit testing easier (you get compile-time type checking instead of the generic IResult).

app.MapGet("/orders/{id}", Results<Ok<Order>, NotFound> (int id, IOrderService service) =>
{
    var order = service.GetById(id);

    return order is null
        ? TypedResults.NotFound()
        : TypedResults.Ok(order);
});

Here, the Results, NotFound> return type explicitly documents all possible response types for the endpoint — this metadata flows automatically into OpenAPI/Swagger without needing .Produces() calls.

Multiple possible outcomes example:

app.MapPost("/orders", Results<Created<Order>, BadRequest<string>> (OrderDto dto, IOrderService service) =>
{
    if (dto.Quantity <= 0)
        return TypedResults.BadRequest("Invalid quantity.");

    var order = service.CreateOrder(dto);
    return TypedResults.Created($"/orders/{order.Id}", order);
});

Custom status code:

app.MapGet("/legacy", () => Results.StatusCode(410)); // 410 Gone

Key interview point to mention:

Prefer TypedResults over Results when possible — it:

• Provides compile-time safety over which result types an endpoint can return.
• Automatically generates accurate OpenAPI metadata (status codes + response types) without manual .Produces() annotations.
• Makes endpoints easier to unit test since you assert on concrete types instead of the generic IResult interface.

Good soundbite: “Results gives you IResult; TypedResults gives you the same functionality but with concrete types, which pays off in better OpenAPI docs and more testable, compile-time–checked endpoints.”

44. What are endpoint filters and how are endpoint filters different from middleware ?

Endpoint filters (IEndpointFilter) are a Minimal API feature (introduced in .NET 7) that let you run logic before and/or after a specific endpoint handler executes — without cluttering the handler itself. They give you access to the strongly-typed route handler arguments, which middleware cannot see.

Basic example:

public class LoggingFilter : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext context,
        EndpointFilterDelegate next)
    {
        Console.WriteLine($"Handling request: {context.HttpContext.Request.Path}");

        var result = await next(context); // call the next filter / the handler itself

        Console.WriteLine($"Response generated: {result}");

        return result;
    }
}

app.MapGet(“/orders/{id}”, (int id) => $”Order {id}”)
.AddEndpointFilter();

Applying multiple filters (they run in order, like a pipeline):

app.MapPost("/orders", (OrderDto order) => Results.Created("/orders/1", order))
   .AddEndpointFilter<ValidationFilter<OrderDto>>()
   .AddEndpointFilter<LoggingFilter>();

Inline filter (lambda-based, for quick logic):

app.MapGet("/orders/{id}", (int id) => $"Order {id}")
   .AddEndpointFilter(async (context, next) =>
   {
       var id = context.GetArgument<int>(0);
       if (id <= 0)
           return Results.BadRequest("Invalid ID");

       return await next(context);
   });

Short-circuiting:

Just like middleware, a filter can choose not to call next(), short-circuiting the pipeline and returning immediately (e.g., failed validation, unauthorized access).

Key Differences: Endpoint Filters vs Middleware

Conceptual analogy:

• Middleware = concentric layers wrapping the entire request pipeline (onion model) — it doesn’t know or care which endpoint eventually handles the request.
• Endpoint filters = a pipeline scoped to one endpoint’s invocation — closer to “method interceptors” or “action filters” in MVC (similar to IActionFilter), but for Minimal APIs.

When to use which:

• Use middleware for concerns that apply broadly across many/most routes regardless of what they do: authentication, HTTPS redirection, CORS, global exception handling, response compression.
• Use endpoint filters for concerns tied to the specific inputs/outputs of certain endpoints: request validation against a specific DTO, argument logging, transforming a specific endpoint’s result, applying business rules only relevant to a subset of routes.

Entity Framework Core Interview Questions

EF Core is Microsoft’s modern, open-source, cross-platform Object-Relational Mapper (ORM) for .NET. It lets you work with a database using .NET objects (classes) instead of writing raw SQL — you query and manipulate data using C# and LINQ, and EF Core translates that into SQL behind the scenes.

EF Core questions are less about memorizing method names and more a filter for practical, production-grade .NET experience — efficient querying, understanding abstractions instead of just using them, and making sensible architecture calls. That’s exactly why they show up so often in interviews.

Why EF Core Interview Questions Matter:

EF Core comes up constantly in .NET interviews because it sits at the intersection of a few things employers actually care about in day-to-day work:

• It’s the default data access story for .NET
• It reveals whether you understand what’s happening under the hood
• Performance and scaling questions live here
• It tests architectural judgment
• Migrations = real-world team workflow

45. what is DbContext ? What happens internally when SaveChanges() is called ?

DbContext is the primary class in EF Core that represents a session with the database. It’s the bridge between your C# objects and the underlying database, responsible for:

• Querying the database (via DbSet<T> properties)
• Tracking changes made to entity instances in memory
• Persisting changes back to the database (SaveChanges())
• Managing the connection lifecycle
• Configuring the model (relationships, keys, constraints) via OnModelCreating
• Caching a first-level “identity map” — within one DbContext instance, querying the same entity twice returns the same object reference

Basic shape:

public class AppDbContext : DbContext
{
    public DbSet<Order> Orders { get; set; }
    public DbSet<Customer> Customers { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Order>()
            .HasOne(o => o.Customer)
            .WithMany(c => c.Orders)
            .HasForeignKey(o => o.CustomerId);
    }
}

Key characteristics:

What Happens Internally When SaveChanges() Is Called?

This is the meatier part of the question — here’s the internal sequence:

a. DetectChanges() runs

EF Core walks through every tracked entity and compares its current property values against the original snapshot values captured when the entity was first queried/attached. This is how it figures out what actually changed without you telling it explicitly.

Note: With ChangeTracker.AutoDetectChangesEnabled, this normally happens automatically before SaveChanges(), before LINQ queries, and at a few other trigger points. You can disable it and call ChangeTracker.DetectChanges() manually for performance-sensitive bulk scenarios.

b. Each tracked entity’s state is evaluated

c. A change set / execution plan is built

EF Core groups the pending Added/Modified/Deleted entries and determines the correct order of operations — respecting foreign key dependencies. For example, a parent entity must be inserted before a dependent child entity that references its generated key (this matters a lot with auto-generated identity/primary keys).

d. A database transaction is started (implicitly)

If you didn’t start one manually, EF Core wraps all the generated SQL statements from this SaveChanges() call in an implicit transaction. This guarantees atomicity — either all changes commit, or none do, if any statement fails.

e. SQL statements are generated and sent to the database

• By default, EF Core batches multiple INSERT/UPDATE/DELETE statements into fewer round trips where the provider supports it (SQL Server, for example, batches statements).
• Parameterized SQL is used (protects against SQL injection and enables plan caching).

f. Generated keys are propagated back

For Added entities with database-generated keys (identity columns), EF Core reads back the newly generated primary key values from the database and updates the in-memory entity objects with them.

g. Concurrency tokens are checked (if configured)

If the entity has a concurrency token (e.g., [Timestamp]/RowVersion column, or a property marked IsConcurrencyToken), the generated UPDATE/DELETE includes a WHERE clause checking the original value. If zero rows are affected (meaning someone else already changed/deleted the row), EF Core throws a DbUpdateConcurrencyException.

h. Transaction commits (or rolls back on failure)

If everything succeeds, the transaction commits. If any statement fails (constraint violation, concurrency conflict, connection issue), the transaction rolls back and EF Core throws (DbUpdateException or DbUpdateConcurrencyException).

i. Change tracker state resets

After a successful save:

• Added entities become Unchanged (now that they exist in the DB)
• Modified entities become Unchanged
• Deleted entities are detached from the context entirely
• The “original values” snapshot is refreshed to match current values, so the next SaveChanges() only picks up new changes

j. SaveChanges() returns an int

Specifically, the number of rows affected in the database (or state entries written) — useful as a lightweight way to confirm something actually happened.

Visual summary:

SaveChanges() called
        ↓
DetectChanges() — diff current vs. original snapshot values
        ↓
Determine entity states (Added / Modified / Deleted)
        ↓
Order operations respecting FK dependencies
        ↓
Begin implicit transaction (if none active)
        ↓
Generate + execute parameterized SQL (batched where possible)
        ↓
Read back DB-generated keys → update tracked entities
        ↓
Check concurrency tokens (throw if conflict)
        ↓
Commit transaction (or rollback on error)
        ↓
Reset entity states to Unchanged / detach Deleted entities
        ↓
Return count of affected rows

46. What is the Change Tracker ? What are entity states in EF Core ?

The Change Tracker (ChangeTracker) is a component owned by every DbContext instance that monitors the state of entity instances the context knows about — whether they were retrieved from the database, added, or manually attached. Its job is to figure out what changed so that SaveChanges() knows exactly which INSERT/UPDATE/DELETE statements to generate.

You can access it directly:

var entries = context.ChangeTracker.Entries();

foreach (var entry in entries)
{
    Console.WriteLine($"{entry.Entity.GetType().Name} — {entry.State}");
}

How it works internally:

• When an entity is queried, EF Core takes a snapshot of its original property values at that moment and starts tracking it.
• As you mutate properties on that entity in memory, the object itself changes — but the original snapshot stays frozen.
• When DetectChanges() runs (automatically before SaveChanges(), before queries, etc.), EF Core compares current values vs. original snapshot values property-by-property to determine what’s actually different.
• Based on that diff, it assigns/updates the entity’s state.

Change tracking strategies:

Accessing/manipulating tracked entries directly:

var entry = context.Entry(order);

Console.WriteLine(entry.State); // e.g. Modified

// Check specific property changes
var originalQty = entry.Property(o => o.Quantity).OriginalValue;
var currentQty = entry.Property(o => o.Quantity).CurrentValue;
bool isModified = entry.Property(o => o.Quantity).IsModified;

Entity States in EF Core

Every tracked entity has an EntityState (an enum) at any given time:

How entities transition between states:

// Detached → Added
var newOrder = new Order { ProductName = "Widget" };
context.Orders.Add(newOrder);           // state: Added

// Query result → Unchanged (automatically tracked)
var order = context.Orders.First();     // state: Unchanged

// Unchanged → Modified (automatic, via change detection)
order.Quantity = 99;                    // still Unchanged in memory...
context.ChangeTracker.DetectChanges();  // ...now becomes Modified

// Unchanged/Modified → Deleted
context.Orders.Remove(order);           // state: Deleted

// After successful SaveChanges()
// Added    → Unchanged
// Modified → Unchanged
// Deleted  → Detached (removed from tracker entirely)

47. What is DbSet<t> ?

DbSet<T> is a class in EF Core that represents a collection of entities of a given type that can be queried and manipulated against the database — conceptually, it maps to a table (or a queryable view/set of rows) in the underlying database.

It’s exposed as a property on your DbContext, and it’s the main entry point for interacting with a specific entity type.

public class AppDbContext : DbContext
{
    public DbSet<Order> Orders { get; set; }
    public DbSet<Customer> Customers { get; set; }
}

What DbSet<T> gives you:

a. Querying (it implements IQueryable<T>)

var bigOrders = context.Orders
    .Where(o => o.Quantity > 10)
    .OrderBy(o => o.ProductName)
    .ToList();

Because DbSet<T> implements IQueryable<T>, LINQ expressions built against it are translated into SQL and executed on the database — not run in memory (this matters a lot; see IQueryable vs IEnumerable below).

b. Adding entities

context.Orders.Add(new Order { ProductName = "Widget", Quantity = 5 });
context.Orders.AddRange(order1, order2, order3);

Marks the entity as Added in the Change Tracker — it will generate an INSERT on SaveChanges().

c. Removing entities

context.Orders.Remove(order);
context.Orders.RemoveRange(order1, order2);

Marks the entity as Deleted — generates a DELETE on SaveChanges().

d. Updating entities

context.Orders.Update(order);

Marks the entire entity graph as Modified (used mainly in disconnected scenarios where the entity wasn’t already tracked).

e. Finding by primary key

var order = context.Orders.Find(5);
// or async
var order = await context.Orders.FindAsync(5);

Find/FindAsync first checks the Change Tracker’s local cache (identity map) before hitting the database — if the entity with that key is already tracked in memory, it’s returned without a database round trip.

48. What is change tracking ? What is AsNoTracking()?

Change Tracking is the mechanism by which EF Core’s DbContext monitors entities that have been loaded (via queries) or attached to it, so it knows what changes have been made in memory and can generate the correct SQL (INSERT, UPDATE, DELETE) when SaveChanges() is called.

How it works:

1. When you query entities using a DbContext (e.g., context.Employees.ToList()), EF Core creates a snapshot of each entity’s original values and starts tracking it.
2. Each tracked entity has an internal state, represented by the EntityState enum:
   • Added – new entity, will be inserted
   • Unchanged – no modifications since it was loaded
   • Modified – one or more properties changed
   • Deleted – marked for deletion
   • Detached – not being tracked
3. When you modify a property on a tracked entity, EF Core compares the current value to the snapshot and marks the entity (and the specific properties) as Modified.
4. When SaveChanges() is called, EF Core inspects the tracked entities’ states and generates the appropriate SQL statements only for what actually changed.

var employee = context.Employees.First(e => e.Id == 1); // tracked
employee.Salary = 50000; // EF detects this change automatically

context.SaveChanges(); // generates UPDATE ... SET Salary = 50000 WHERE Id = 1

You didn’t have to explicitly call Update() — EF Core detected the change itself via tracking.

Why it matters (interview angle):

• It enables the “just modify the object” programming model instead of manually writing UPDATE statements.
• It has a performance cost: EF Core keeps snapshots and does change detection (DetectChanges()), which takes memory and CPU, especially with large result sets.
• It’s central to concepts like the Unit of Work pattern that DbContext implements.

AsNoTracking()

AsNoTracking() is a query extension method that tells EF Core not to track the entities returned by that query. The entities are returned as plain objects with no snapshot kept, and no EntityState is maintained for them.

var employees = context.Employees
    .AsNoTracking()
    .Where(e => e.DepartmentId == 3)
    .ToList();

Key characteristics:

• Read-only intent: Since there’s no tracking, changes to these entities won’t be detected or persisted by SaveChanges() unless you explicitly attach them again.
• Performance benefit: Skips the overhead of creating snapshots and change-detection, making queries faster and more memory-efficient — especially valuable for:
  • Reporting queries
  • API GET endpoints that just return data
  • Large result sets
• Can be applied per-query (.AsNoTracking()) or set as a context-wide default:

context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;

There’s also AsNoTrackingWithIdentityResolution(), which avoids full tracking overhead but still ensures that the same logical entity (same key) maps to the same object instance within that query’s results — useful when a query has duplicate/related rows for the same entity.

49. Explain Added, Modified, Deleted, Unchanged, and Detached

Every entity that EF Core knows about (tracked entities) has a state, represented by the EntityState enum. This state tells SaveChanges() exactly what SQL operation to generate for that entity.

public enum EntityState
{
    Detached,
    Unchanged,
    Deleted,
    Modified,
    Added
}

You can inspect it at any time:

var state = context.Entry(employee).State;

a. Detached

The entity exists as a .NET object, but the DbContext is not tracking it at all. EF knows nothing about it — no snapshot, no state management.

var employee = new Employee { Name = "John" }; // Detached — just created, not added to context

An entity also becomes Detached again if you explicitly call context.Entry(entity).State = EntityState.Detached, or after the context is disposed.

b. Added

The entity is new and tracked, and will be inserted into the database on the next SaveChanges(). Its primary key (if database-generated) is typically not yet set to a real value.

context.Employees.Add(employee); // state becomes Added
context.SaveChanges(); // generates INSERT

c. Unchanged

The entity is tracked, and its current property values match the original snapshot EF Core took when it was loaded. No SQL is generated for this entity on SaveChanges().

var employee = context.Employees.First(); // state is Unchanged right after loading

d. Modified

The entity is tracked, and at least one property value differs from its original snapshot. EF Core tracks changes at the property level, not just entity level — so it knows exactly which columns to include in the UPDATE statement.

employee.Salary = 60000; // state becomes Modified
context.SaveChanges(); // generates UPDATE ... SET Salary = 60000 WHERE Id = ...

e. Deleted

The entity is tracked and marked for removal. On SaveChanges(), EF Core generates a DELETE statement using the entity’s key.

context.Employees.Remove(employee); // state becomes Deleted
context.SaveChanges(); // generates DELETE FROM Employees WHERE Id = ...

State transition summary:

50. What is eager loading, lazy loading and explicit loading ?

EF Core offers three strategies for loading related (navigation property) data. This is a very common interview question because it tests both API knowledge and performance judgment.

Eager Loading

Related data is loaded upfront, as part of the same query, using Include() (and ThenInclude() for deeper levels).

var employees = context.Employees
    .Include(e => e.Department)
    .ThenInclude(d => d.Location)
    .Include(e => e.Projects)
    .ToList();

This generates a single SQL query (typically using JOINs) that pulls employees along with their departments, locations, and projects all at once.

When to use:

• You know upfront you’ll need the related data.
• Avoids the N+1 query problem (see below).

Downside:

• Over-fetching if you don’t actually need the related data every time.
• Multiple Include() calls with collections can cause a cartesian explosion — the result set balloons because of multiple JOINs multiplying row counts. EF Core mitigates this using “split queries” (see below).

// Split query — runs separate SQL queries instead of one big JOIN, avoiding cartesian explosion
var employees = context.Employees
    .Include(e => e.Projects)
    .Include(e => e.Certifications)
    .AsSplitQuery()
    .ToList();

Lazy Loading

Related data is loaded automatically, on-demand, the moment you access a navigation property — not when the initial query runs.

To enable it:

• Install Microsoft.EntityFrameworkCore.Proxies
• Enable it in DbContext configuration: optionsBuilder.UseLazyLoadingProxies()
• Mark navigation properties as virtual

public class Employee
{
    public int Id { get; set; }
    public string Name { get; set; }
    public virtual Department Department { get; set; } // must be virtual
}

var employee = context.Employees.First(); // only Employee is loaded
var deptName = employee.Department.Name; // triggers a SEPARATE query here, behind the scenes

When to use:

• Rarely recommended for anything but small, exploratory scenarios.

Downside (important interview point):

• Causes the infamous N+1 query problem — if you loop over 100 employees and access .Department on each, that’s 1 query for employees + 100 separate queries for departments.

foreach (var emp in employees) // 1 query already ran
{
    Console.WriteLine(emp.Department.Name); // N additional queries!
}

• Requires proxies and virtual properties, which some consider an anti-pattern (breaks POCO purity, has gotchas with sealed classes/structs).
• Easy to accidentally trigger from serialization frameworks (e.g., a JSON serializer touching every navigation property).

Explicit Loading

You load the initial entity without related data, then explicitly and deliberately trigger loading of specific navigation properties when you choose to, using context.Entry().

var employee = context.Employees.First(); // just Employee, nothing else

// Explicitly load a reference navigation property
context.Entry(employee).Reference(e => e.Department).Load();

// Explicitly load a collection navigation property
context.Entry(employee).Collection(e => e.Projects).Load();

// You can even filter what gets loaded
context.Entry(employee).Collection(e => e.Projects)
    .Query()
    .Where(p => p.IsActive)
    .Load();

When to use:

• You need related data only conditionally (e.g., inside an if block, based on business logic).
• You want the control of lazy loading’s “load only if needed” without the hidden magic and N+1 risk of automatic lazy loading — the loading call is visible in the code.

Comparison Table:

51. What is the difference between Include() and ThenInclude() ?

Both are used for eager loading of related data, but they operate at different levels of the object graph.

Include()

Loads a navigation property directly on the entity you’re querying (first level of relation).

var employees = context.Employees
    .Include(e => e.Department)
    .ToList();

This loads each Employee along with its direct Department.

You can also chain multiple Include() calls to load several sibling (first-level) navigation properties independently:

var employees = context.Employees
    .Include(e => e.Department)
    .Include(e => e.Projects)
    .ToList();

This loads Department and Projects, both directly related to Employee.

ThenInclude()

Loads a navigation property on an entity that was just included — i.e., it goes one level deeper into the object graph, continuing from the previous Include()/ThenInclude().

var employees = context.Employees
    .Include(e => e.Department)
    .ThenInclude(d => d.Location)
    .ToList();

This loads Employee → Department → Location. Without ThenInclude(), there’s no way to express “go one level deeper” — Include() alone only knows about the root entity’s navigation properties.

Combining them — branching the graph:

You can mix multiple Include/ThenInclude chains to load a complex graph. Each new Include() call starts a new branch from the root entity:

var employees = context.Employees
    .Include(e => e.Department)
        .ThenInclude(d => d.Location)
    .Include(e => e.Projects)
        .ThenInclude(p => p.Client)
    .ToList();

This produces:

Employee
 ├── Department
 │     └── Location
 └── Projects
       └── Client

The second Include(e => e.Projects) resets the “current level” back to the root Employee, so the interviewer should know that ThenInclude() always continues from the immediately preceding Include/ThenInclude in that chain — not from wherever the chain “ended up.”

Multiple levels deep:

You can chain ThenInclude() multiple times to go arbitrarily deep:

var employees = context.Employees
    .Include(e => e.Department)
        .ThenInclude(d => d.Location)
            .ThenInclude(l => l.Country)
    .ToList();

Employee → Department → Location → Country

A gotcha worth mentioning:

If you need to include a navigation property on a collection’s element type (e.g., a collection navigation on each item inside another collection), ThenInclude() handles that too — EF Core infers you’re operating on the element type of the enclosing collection:

context.Departments
    .Include(d => d.Employees)
        .ThenInclude(e => e.Projects)
    .ToList();

This loads all Employees for each Department, and all Projects for each of those Employees — correctly handling the one-to-many-to-many nesting.

52. What is the difference between EnsureCreated() and EF Core Migrations ?

Both can be used to get a database schema in place from your EF Core model, but they’re designed for very different scenarios and are not compatible with each other.

Database.EnsureCreated()

context.Database.EnsureCreated();

What it does:

• Checks if the database exists. If not, creates it.
• Creates the schema (tables, columns, keys, indexes) directly from the current state of your EF Core model — in one shot.
• If the database already exists, it does nothing (doesn’t check if the schema matches the model).

Key characteristics:

• Does not use or create a migrations history table (__EFMigrationsHistory).
• Does not support incremental schema changes — there’s no concept of “diffing” old vs new model versions.
• If you change your model (add a property, new entity, etc.) after the database was created, EnsureCreated() will not update the existing database. You’d have to drop and recreate it.
• Cannot be mixed with Migrations on the same database — they use fundamentally different tracking mechanisms, and EF Core will throw an error if you try to apply migrations to a database created via EnsureCreated().

When to use:

• Unit/integration tests (especially with in-memory or SQLite in-memory providers) where you just need a throwaway schema quickly.
• Quick prototypes, demos, or POCs where schema evolution doesn’t matter.
• Scenarios where you never intend to evolve the schema over time (rare in real apps).

// Typical test setup
var options = new DbContextOptionsBuilder<AppDbContext>()
    .UseInMemoryDatabase("TestDb")
    .Options;

using var context = new AppDbContext(options);
context.Database.EnsureCreated(); // fast, one-time schema creation

EF Core Migrations

dotnet ef migrations add InitialCreate
dotnet ef database update

What it does:

• Generates a versioned migration file (C# code) representing the diff between your current model and the last known model snapshot.
• Maintains a __EFMigrationsHistory table in the database that tracks which migrations have already been applied.
• Allows incremental, repeatable, and reversible schema changes over the lifetime of an application.

Key characteristics:

• Every schema change (add column, rename table, add index, etc.) is captured in its own migration file with Up() and Down() methods — enabling rollback.
• Can be applied programmatically (context.Database.Migrate()) or via CLI/scripts — suitable for CI/CD pipelines.
• Can generate raw SQL scripts (dotnet ef migrations script) for DBA review or production deployment without needing the EF tooling on the production server.
• Supports team collaboration — migration files are checked into source control, so schema history is versioned alongside code.

// Typical production startup
context.Database.Migrate(); // applies any pending migrations

Side-by-side comparison:

Common follow-up: “What about EnsureDeleted()?”

Worth mentioning briefly — context.Database.EnsureDeleted() drops the database entirely if it exists. It’s often paired with EnsureCreated() in test setups to guarantee a clean slate before each test run:

context.Database.EnsureDeleted();
context.Database.EnsureCreated();

53. What is the N+1 query problem ?

In EF Core, it happens when you fetch a set of entities, then access a navigation property on each one in a loop — and EF Core (with lazy loading enabled) fires off a separate query for each entity to resolve that navigation property.

Example:

var blogs = context.Blogs.ToList();  // 1 query — fetches all blogs

foreach (var blog in blogs)
{
    Console.WriteLine(blog.Posts.Count);  // N queries — one per blog to lazy-load Posts
}

If there are 50 blogs, this fires 1 + 50 = 51 queries instead of one efficient query (or two well-batched ones).

Why it happens in EF Core specifically:

• Lazy loading is opt-in but easy to enable — via UseLazyLoadingProxies() and making navigation properties virtual. Once enabled, simply touching a navigation property (blog.Posts) triggers a new round-trip to the database, invisibly.
• Even without lazy loading, developers sometimes manually call .Entry(blog).Collection(b => b.Posts).Load() inside a loop — same effect, just explicit instead of hidden.

How to fix it:

a. Eager loading with Include() / ThenInclude() — the most common EF Core fix:

var blogs = context.Blogs
    .Include(b => b.Posts)
    .ToList();  // 1 query total, using a SQL JOIN

b. Explicit loading, but batched, not per-entity:

var blogIds = blogs.Select(b => b.Id).ToList();
var posts = context.Posts
    .Where(p => blogIds.Contains(p.BlogId))
    .ToList();  // 1 query for all related posts

c. Projection with Select() — often the most efficient, since you only pull the columns you need:

var result = context.Blogs
    .Select(b => new {
        b.Name,
        PostCount = b.Posts.Count()
    })
    .ToList();  // 1 query, translated entirely to SQL

d. Split queries (EF Core 5+) — when Include with multiple collections causes a cartesian explosion instead of N+1, you can tell EF to issue separate-but-batched queries instead of one giant join:

var blogs = context.Blogs
    .Include(b => b.Posts)
    .Include(b => b.Contributors)
    .AsSplitQuery()
    .ToList();

How to catch it:

• Enable EF Core logging: optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information) and watch for repeated similar-looking SELECT statements
• Use context.ChangeTracker.LazyLoadingEnabled = false in development to make lazy-load accidents throw/fail loudly instead of silently querying
• Tools like MiniProfiler or Application Insights can visually flag repeated queries in a request
• As a rule of thumb: if lazy loading proxies are enabled, be very suspicious of any navigation-property access inside a foreach

Key takeaway for EF Core: default to Include() for known access patterns, prefer Select() projections when you don’t need full entities, and treat lazy loading as something to use cautiously (or disable entirely) rather than as the default.

54. What is optimistic concurrency ?

It’s a strategy for handling simultaneous edits to the same data without locking rows — instead of preventing others from reading/editing a record while you have it open, EF Core lets everyone read and edit freely, but checks at save time whether the data changed since you loaded it. If it did, the update is rejected instead of silently overwriting someone else’s changes.

It’s called “optimistic” because it assumes conflicts are rare — so it doesn’t pay the cost of locking upfront, only checks when it actually matters (on save).

The problem it solves:

// User A loads a Blog (Name = "Tech News", RowVersion = 1)
// User B loads the same Blog (Name = "Tech News", RowVersion = 1)

// User A changes Name to "Tech Daily" and saves → RowVersion becomes 2
// User B changes Name to "Tech World" and saves...

Without concurrency control, User B’s save would silently overwrite User A’s change — even though User B never saw it. Optimistic concurrency catches this instead of letting it happen silently.

How it works in EF Core:

You mark a property as a concurrency token. On every UPDATE/DELETE, EF Core includes that property’s original value in the WHERE clause. If no rows match (because someone else already changed it), EF Core throws a DbUpdateConcurrencyException.

a. Using a dedicated RowVersion / Timestamp column (most common, SQL Server):

public class Blog
{
    public int Id { get; set; }
    public string Name { get; set; }

    [Timestamp]
    public byte[] RowVersion { get; set; }  // auto-updated by the DB on every write
}

Generated SQL looks roughly like:

UPDATE Blogs 
SET Name = 'Tech World' 
WHERE Id = 1 AND RowVersion = 0x0000000000000001
-- if 0 rows affected → concurrency conflict

b.Using Fluent API on any property:

modelBuilder.Entity<Blog>()
    .Property(b => b.Name)
    .IsConcurrencyToken();

Now any property you designate (not just a special RowVersion column) gets included in the WHERE clause — if the value in the DB differs from what was originally loaded, the update fails.

c. Handling the conflict:

try
{
    context.SaveChanges();
}
catch (DbUpdateConcurrencyException ex)
{
    foreach (var entry in ex.Entries)
    {
        var databaseValues = entry.GetDatabaseValues();
        
        if (databaseValues == null)
        {
            // Row was deleted by someone else
        }
        else
        {
            var currentValues = entry.CurrentValues;
            var originalValues = entry.OriginalValues;

            // Decide: overwrite with client's values, 
            // keep the database's values, 
            // or merge/prompt the user
            entry.OriginalValues.SetValues(databaseValues); // common: refresh original values, then retry
        }
    }

    context.SaveChanges(); // retry after resolving
}

Optimistic vs. Pessimistic concurrency

EF Core supports optimistic concurrency natively and it’s the default recommended approach for typical web apps — pessimistic locking isn’t really a first-class EF Core feature and would need manual transaction/locking code. Use a [Timestamp] RowVersion column for the simplest, most reliable setup.

55. What is a transaction in EF Core?

A transaction is a way to group multiple database operations together so they either all succeed or all fail as one unit — there’s no in-between state where only some of the changes got applied.

The default behavior (implicit transaction):

You often don’t need to think about this because SaveChanges() already wraps itself in a transaction automatically. If you modify multiple entities and call SaveChanges() once, EF Core executes all the resulting SQL statements inside a single transaction — if any statement fails, everything rolls back.

context.Blogs.Add(new Blog { Name = "Tech News" });
context.Posts.Add(new Post { Title = "Hello World", BlogId = 1 });

context.SaveChanges(); 
// Both inserts happen in ONE implicit transaction.
// If the second insert fails, the first is rolled back too.

When you need an explicit transaction:

The implicit one only covers a single SaveChanges() call. If you need to span multiple SaveChanges() calls, or mix EF Core with raw SQL, you need to manage the transaction explicitly.

using var transaction = context.Database.BeginTransaction();

try
{
    context.Blogs.Add(new Blog { Name = "Tech News" });
    context.SaveChanges(); // SaveChanges #1

    context.Posts.Add(new Post { Title = "Hello World", BlogId = 1 });
    context.SaveChanges(); // SaveChanges #2

    transaction.Commit(); // only now are changes actually persisted
}
catch (Exception)
{
    transaction.Rollback(); // undo everything if anything failed
    throw;
}

Or more concisely with EnsureTransaction / the built-in execution strategy wrapper:

using var transaction = context.Database.BeginTransaction();
try
{
    // multiple operations, possibly raw SQL too
    context.Database.ExecuteSqlRaw("UPDATE Blogs SET Name = 'X' WHERE Id = 1");
    context.SaveChanges();
    transaction.Commit();
}
catch
{
    transaction.Rollback();
    throw;
}

Transactions across multiple DbContext instances:

If you need one transaction to span two separate DbContexts (e.g., two different bounded contexts), EF Core supports sharing a connection/transaction:

using var connection = new SqlConnection(connectionString);
connection.Open();
using var transaction = connection.BeginTransaction();

using (var context1 = new BlogContext(new DbContextOptionsBuilder<BlogContext>()
        .UseSqlServer(connection).Options))
{
    context1.Database.UseTransaction(transaction);
    // ... operations
}

using (var context2 = new OrderContext(new DbContextOptionsBuilder<OrderContext>()
        .UseSqlServer(connection).Options))
{
    context2.Database.UseTransaction(transaction);
    // ... operations
}

transaction.Commit();

Working with retry-resilient providers (e.g., EnableRetryOnFailure):

If you’ve enabled an execution strategy (like automatic retries for transient SQL Server failures), you can’t just call BeginTransaction() directly — the whole block, including retries, needs to be wrapped:

var strategy = context.Database.CreateExecutionStrategy();

strategy.Execute(() =>
{
    using var transaction = context.Database.BeginTransaction();
    
    context.Blogs.Add(new Blog { Name = "Tech News" });
    context.SaveChanges();

    context.Posts.Add(new Post { Title = "Hello World" });
    context.SaveChanges();

    transaction.Commit();
});

This is necessary because if a transient failure happens mid-transaction and a naive retry just re-runs the code, you could end up trying to begin a transaction inside an already-failed one — CreateExecutionStrategy() handles this correctly.

Savepoints (EF Core 5+):

Within a transaction, you can mark savepoints to roll back to a partial point without discarding the whole transaction:

using var transaction = context.Database.BeginTransaction();

context.Blogs.Add(new Blog { Name = "A" });
context.SaveChanges();
transaction.CreateSavepoint("AfterFirstBlog");

context.Blogs.Add(new Blog { Name = "B" });
context.SaveChanges();

// something went wrong with "B" specifically
transaction.RollbackToSavepoint("AfterFirstBlog"); // "A" is kept, "B" is undone

transaction.Commit();

Key takeaway:

• Single SaveChanges() call → transaction is automatic, no code needed.
• Multiple SaveChanges() calls, or mixing with raw SQL → use BeginTransaction() / Commit() / Rollback() explicitly.
• Using EnableRetryOnFailure → wrap explicit transactions in CreateExecutionStrategy().Execute(...).

Authentication & Authorization Interview Questions

Authentication and Authorization are two of the most heavily tested topics in ASP.NET Core interviews. Authentication answers “who are you?” — verifying identity via credentials, tokens, or external providers — while Authorization answers “what are you allowed to do?”, determining access after identity is confirmed. Interviewers typically go beyond definitions to probe the mechanics: middleware pipeline order (UseAuthentication() before UseAuthorization()), JWT vs. cookie-based auth, ASP.NET Core Identity, and role-based vs. policy-based vs. claims-based authorization. Scenario questions are common too — like restricting an endpoint by a specific claim/role combo, or debugging why a valid user gets a 403 — testing whether you can apply the concepts, not just recite them.

These topics carry weight because security mistakes are among the costliest a developer can make — a broken authorization check can mean data breaches or full system compromise, unlike a minor UI bug. Interviewers use Auth questions as a proxy for engineering maturity and “secure by default” thinking, so candidates who explain the full lifecycle clearly — login, token issuance, claims validation, fine-grained authorization — tend to stand out, while textbook-only answers invite deeper follow-ups that expose gaps. For mid-level and senior roles especially, this is often a make-or-break area, so it’s worth mastering rather than just memorizing.

56. What is the difference between authentication and authorization ?

Authentication

The process of verifying who the user is — checking credentials (username/password), a token (JWT), a cookie, or an external identity provider (Google, Microsoft, etc.), and establishing a ClaimsPrincipal representing the user.

// Program.cs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            // ...
        };
    });

app.UseAuthentication(); // must come BEFORE UseAuthorization

If authentication fails (bad/missing credentials), the server responds with 401 Unauthorized — “I don’t know who you are.”

Authorization

Once the user’s identity is established, authorization decides what that user is permitted to do — based on roles, claims, or custom policies.

[Authorize(Roles = "Admin")]
[HttpDelete("{id}")]
public IActionResult DeleteUser(int id) { ... }

// Policy-based
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("MinimumAge", policy =>
        policy.RequireAssertion(context =>
            context.User.HasClaim(c => c.Type == "Age") &&
            int.Parse(context.User.FindFirst("Age").Value) >= 18));
});

app.UseAuthorization(); // must come AFTER UseAuthentication

If the user is authenticated but lacks the required role/claim/policy, the server responds with 403 Forbidden — “I know who you are, but you’re not allowed to do this.”

Key relationship

Authentication always happens before Authorization in the pipeline — you can’t check what someone can do until you know who they are. That’s also why middleware order matters:

app.UseAuthentication(); // 1. Establish identity
app.UseAuthorization();  // 2. Check permissions

Getting this order wrong (or reversing it) is a classic interview trick question, since misconfigured middleware order can silently allow unauthorized access or unexpectedly block valid users — a good example of why this distinction matters more in practice than it might seem in theory.

57. What is a Claims and Policies in ASP.NET Core authorization

A Claim is a key-value pair that represents information about a user, issued by a trusted party (typically during authentication). It’s part of the ClaimsIdentity/ClaimsPrincipal model.

// Examples of claims
new Claim(ClaimTypes.Name, "John Doe")
new Claim(ClaimTypes.Email, "john@example.com")
new Claim("EmployeeId", "12345")
new Claim("Department", "Engineering")

Each claim has:

• Type – what the claim represents (e.g., "Department")
• Value – the actual data (e.g., "Engineering")
• Issuer (optional) – who issued the claim

Claims are typically added during authentication (login) and bundled into a ClaimsIdentity, which becomes part of the ClaimsPrincipal (User object) accessible throughout the request.

var claims = new List<Claim>
{
    new Claim(ClaimTypes.Name, "jdoe"),
    new Claim("Department", "Engineering")
};
var identity = new ClaimsIdentity(claims, "MyAuthScheme");
var principal = new ClaimsPrincipal(identity);

You can check claims directly in code:

if (User.HasClaim("Department", "Engineering"))
{
    // allow access
}

Policy

A Policy is a named, reusable set of authorization requirements — often built using one or more claims — registered centrally so it can be applied via attributes instead of writing manual checks everywhere.

a. Registering a policy (in Program.cs):

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("EngineeringOnly", policy =>
        policy.RequireClaim("Department", "Engineering"));

    options.AddPolicy("MinimumAge", policy =>
        policy.Requirements.Add(new MinimumAgeRequirement(18)));
});

b. Applying it to a controller or endpoint:

[Authorize(Policy = "EngineeringOnly")]
public IActionResult SecretPage()
{
    return View();
}

Policies can be simple (RequireClaim, RequireRole, RequireAuthenticatedUser) or complex, using a custom IAuthorizationRequirement and AuthorizationHandler<T> for logic beyond a simple claim check (e.g., “user must be over 18,” verified via a date-of-birth claim).

How they relate:

In short: claims describe the user, and policies define the rules used to decide whether those claims are sufficient to authorize access.

58. What is role-based authorization ?

Role-based authorization restricts access to resources based on the role(s) a user belongs to (e.g., Admin, Manager, User) rather than checking individual permissions or claims one by one. It’s one of the simplest and most common authorization models.

How it works:

• A role is essentially just a special claim of type ClaimTypes.Role.
• When a user is authenticated, their roles are added to the ClaimsPrincipal.
• Authorization checks whether the current user belongs to a required role before granting access.

var claims = new List<Claim>
{
    new Claim(ClaimTypes.Name, "jdoe"),
    new Claim(ClaimTypes.Role, "Admin")
};
var identity = new ClaimsIdentity(claims, "MyAuthScheme");
var principal = new ClaimsPrincipal(identity);

Applying role-based authorization

a. Using the [Authorize] attribute:

[Authorize(Roles = "Admin")]
public IActionResult AdminPanel()
{
    return View();
}

b. Multiple roles (OR logic) — user needs any one of the listed roles:

[Authorize(Roles = "Admin,Manager")]
public IActionResult ManageUsers()
{
    return View();
}

c. Multiple [Authorize] attributes (AND logic) — user must satisfy all of them:

[Authorize(Roles = "Admin")]
[Authorize(Roles = "HR")]
public IActionResult SensitiveAction()
{
    return View();
}

d. Checking roles in code:

if (User.IsInRole("Admin"))
{
    // perform admin-only logic
}

e. Role-based policies (useful when combining with other requirements):

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("AdminOnly", policy =>
        policy.RequireRole("Admin"));
});

[Authorize(Policy = "AdminOnly")]
public IActionResult SecretSettings()
{
    return View();
}

Key points:

Role-based vs. Claim-based vs. Policy-based

• Role-based → coarse-grained, checks a single “Role” claim (good for simple hierarchies like Admin/User).
• Claim-based → checks any claim type/value (e.g., Department = "Engineering"), more flexible.
• Policy-based → the most flexible; can combine roles, claims, and custom logic into a single named rule — and is the recommended approach in ASP.NET Core going forward, since roles and claims can both be expressed as policies.

59. What is policy-based authorization ?

Policy-based authorization is the most flexible and recommended authorization model in ASP.NET Core. Instead of scattering role or claim checks throughout your code, you define named policies centrally — each policy is a set of one or more requirements that must be satisfied — and then apply that policy declaratively wherever needed.

It’s the underlying model that role-based and claims-based authorization are actually built on top of.

Core building blocks:

a. Simple policies (built-in requirements)

You don’t always need custom requirements — simple policies can use built-in methods:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("EngineeringOnly", policy =>
        policy.RequireClaim("Department", "Engineering"));

    options.AddPolicy("AdminOnly", policy =>
        policy.RequireRole("Admin"));

    options.AddPolicy("MustBeAuthenticated", policy =>
        policy.RequireAuthenticatedUser());
});

b. Custom policies (custom requirement + handler)

For logic that goes beyond a single claim check — e.g., “user must be at least 18 years old.”

Step 1 – Define the requirement:

public class MinimumAgeRequirement : IAuthorizationRequirement
{
    public int MinimumAge { get; }
    public MinimumAgeRequirement(int minimumAge) => MinimumAge = minimumAge;
}

Step 2 – Create the handler:

public class MinimumAgeHandler : AuthorizationHandler<MinimumAgeRequirement>
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context, MinimumAgeRequirement requirement)
    {
        var dobClaim = context.User.FindFirst(c => c.Type == ClaimTypes.DateOfBirth);
        if (dobClaim == null)
            return Task.CompletedTask;

        var dob = DateTime.Parse(dobClaim.Value);
        var age = DateTime.Today.Year - dob.Year;

        if (age >= requirement.MinimumAge)
            context.Succeed(requirement);

        return Task.CompletedTask;
    }
}

Step 3 – Register the handler and policy:

builder.Services.AddSingleton<IAuthorizationHandler, MinimumAgeHandler>();

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("MinimumAge18", policy =>
        policy.Requirements.Add(new MinimumAgeRequirement(18)));
});

Step 4 – Apply it:

[Authorize(Policy = "MinimumAge18")]
public IActionResult AdultContent()
{
    return View();
}

c. Combining multiple requirements

A policy can require several things at once — all requirements must succeed:

options.AddPolicy("SeniorEngineer", policy =>
{
    policy.RequireRole("Engineer");
    policy.RequireClaim("Level", "Senior");
    policy.Requirements.Add(new MinimumAgeRequirement(21));
});

d. Imperative checks (outside attributes)

Using IAuthorizationService when you need to check a policy in code, e.g., inside a Razor Page or controller action:

public class DocumentController : Controller
{
    private readonly IAuthorizationService _authorizationService;

    public DocumentController(IAuthorizationService authorizationService)
    {
        _authorizationService = authorizationService;
    }

    public async Task<IActionResult> Edit(Document doc)
    {
        var result = await _authorizationService.AuthorizeAsync(User, doc, "EditPolicy");
        if (!result.Succeeded)
            return Forbid();

        return View(doc);
    }
}

This example also shows resource-based authorization — passing the actual resource (doc) so the handler can check ownership or other resource-specific rules, not just claims on the user.

Why policy-based is preferred:

• Centralized – all authorization rules live in one place (Program.cs / a startup extension), not scattered across controllers.
• Reusable – one policy can be applied to many endpoints.
• Composable – combine roles, claims, and custom logic in a single policy.
• Testable – handlers are plain classes that can be unit tested independently.
• Extensible – supports resource-based authorization for per-object rules (e.g., “only the document owner can edit”).

Quick comparison:

60. What is claims-based authorization ?

Claims-based authorization restricts access based on the presence (and optionally the value) of specific claims in the user’s ClaimsPrincipal — rather than relying purely on roles. A claim is a key-value pair issued by a trusted party (e.g., "Department" = "Engineering", "EmployeeId" = "12345"), so this model lets you authorize based on any attribute of the user, not just a fixed role name.

It sits conceptually between role-based (single, coarse Role claim) and full policy-based authorization (which claims-based checks are actually built on top of).

How claims get into the user:

Claims are added during authentication and bundled into a ClaimsIdentity → ClaimsPrincipal:

var claims = new List<Claim>
{
    new Claim(ClaimTypes.Name, "jdoe"),
    new Claim("Department", "Engineering"),
    new Claim("EmployeeId", "12345"),
    new Claim(ClaimTypes.DateOfBirth, "2000-05-10")
};
var identity = new ClaimsIdentity(claims, "MyAuthScheme");
var principal = new ClaimsPrincipal(identity);

Applying claims-based authorization

Unlike roles, there’s no [Authorize(Claim = "...")] shortcut attribute — claims checks are expressed through policies.

a. Define a policy that requires a claim:

builder.Services.AddAuthorization(options =>
{
    // Just checks the claim type exists (any value)
    options.AddPolicy("HasEmployeeId", policy =>
        policy.RequireClaim("EmployeeId"));

    // Checks claim type AND specific value(s)
    options.AddPolicy("EngineeringOnly", policy =>
        policy.RequireClaim("Department", "Engineering"));

    // Multiple allowed values (OR)
    options.AddPolicy("EngineeringOrIT", policy =>
        policy.RequireClaim("Department", "Engineering", "IT"));
});

b. Apply it to a controller/endpoint:

[Authorize(Policy = "EngineeringOnly")]
public IActionResult TeamDashboard()
{
    return View();
}

c. Check claims directly in code:

if (User.HasClaim("Department", "Engineering"))
{
    // allow access
}

var employeeId = User.FindFirst("EmployeeId")?.Value;

d. Custom claims logic (beyond a simple match) — use a custom requirement/handler when you need to evaluate a claim’s value with logic (e.g., parsing a date, comparing numbers):

public class MinimumAgeRequirement : IAuthorizationRequirement
{
    public int MinimumAge { get; }
    public MinimumAgeRequirement(int age) => MinimumAge = age;
}

public class MinimumAgeHandler : AuthorizationHandler<MinimumAgeRequirement>
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context, MinimumAgeRequirement requirement)
    {
        var dobClaim = context.User.FindFirst(ClaimTypes.DateOfBirth);
        if (dobClaim != null)
        {
            var age = DateTime.Today.Year - DateTime.Parse(dobClaim.Value).Year;
            if (age >= requirement.MinimumAge)
                context.Succeed(requirement);
        }
        return Task.CompletedTask;
    }
}

Key points:

• A role is just a special-cased claim (ClaimTypes.Role), so role-based authorization is really a narrow form of claims-based authorization.
• Claims-based checks are always wired through AddPolicy + RequireClaim (or a custom handler) — there’s no built-in [Authorize(Claim=...)] attribute.
• Best suited when authorization depends on user attributes beyond a simple role (department, subscription tier, verified email, age, permission flags, etc.).
• Can be combined with roles and custom requirements in the same policy for fine-grained control.

61. What is permission-based authorization ?

Permission-based authorization restricts access based on fine-grained permissions (e.g., "Users.Create", "Orders.Delete", "Reports.View") assigned to a user — rather than broad roles like Admin or Manager. It’s the most granular authorization model: instead of asking “what role is this user?”, it asks “can this user perform this specific action?”

ASP.NET Core has no built-in permission system — it’s typically implemented on top of claims-based and policy-based authorization.

Why permission-based over role-based?

Roles become a problem at scale:

• A Manager role might need 30 different permissions, and hardcoding [Authorize(Roles = "Manager")] everywhere makes it hard to give one manager extra access without creating a new role.
• Permissions decouple “what a user can do” from “what a user is called” — roles become just a convenient bundle of permissions, not the authorization unit itself.

Common implementation approach

a. Model permissions as claims

var claims = new List<Claim>
{
    new Claim(ClaimTypes.Name, "jdoe"),
    new Claim("Permission", "Orders.View"),
    new Claim("Permission", "Orders.Edit"),
    new Claim("Permission", "Reports.View")
};
var identity = new ClaimsIdentity(claims, "MyAuthScheme");

Permissions are usually stored in a database (Roles → Permissions mapping table), and converted into claims when the user logs in / token is issued.

b. Define a custom requirement

public class PermissionRequirement : IAuthorizationRequirement
{
    public string Permission { get; }
    public PermissionRequirement(string permission) => Permission = permission;
}

c. Create the handler

public class PermissionHandler : AuthorizationHandler<PermissionRequirement>
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context, PermissionRequirement requirement)
    {
        if (context.User.HasClaim("Permission", requirement.Permission))
        {
            context.Succeed(requirement);
        }
        return Task.CompletedTask;
    }
}

d. Register a policy per permission — or generate them dynamically

Manually:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("Orders.Edit", policy =>
        policy.Requirements.Add(new PermissionRequirement("Orders.Edit")));
});

Dynamically (better for many permissions), using an IAuthorizationPolicyProvider:

public class PermissionPolicyProvider : IAuthorizationPolicyProvider
{
    public DefaultAuthorizationPolicyProvider FallbackPolicyProvider { get; }

    public PermissionPolicyProvider(IOptions<AuthorizationOptions> options)
    {
        FallbackPolicyProvider = new DefaultAuthorizationPolicyProvider(options);
    }

    public Task<AuthorizationPolicy> GetPolicyAsync(string policyName)
    {
        var policy = new AuthorizationPolicyBuilder()
            .AddRequirements(new PermissionRequirement(policyName))
            .Build();
        return Task.FromResult(policy);
    }

    public Task<AuthorizationPolicy> GetDefaultPolicyAsync() =>
        FallbackPolicyProvider.GetDefaultPolicyAsync();

    public Task<AuthorizationPolicy?> GetFallbackPolicyAsync() =>
        FallbackPolicyProvider.GetFallbackPolicyAsync();
}

builder.Services.AddSingleton<IAuthorizationPolicyProvider, PermissionPolicyProvider>();
builder.Services.AddSingleton<IAuthorizationHandler, PermissionHandler>();

This lets you use any permission string directly as a policy name without pre-registering each one:

[Authorize(Policy = "Orders.Edit")]
public IActionResult EditOrder(int id) { ... }

[Authorize(Policy = "Reports.View")]
public IActionResult ViewReports() { ... }

e. Check permissions imperatively

var result = await _authorizationService.AuthorizeAsync(User, "Orders.Delete");
if (!result.Succeeded)
    return Forbid();

Or directly via claims:

if (User.HasClaim("Permission", "Orders.Delete"))
{
    // allow
}

Typical database design:

At login, the app resolves the user’s roles → collects all associated permissions → issues them as Permission claims (or embeds them in a JWT).

Comparison across all four models:

Key points:

• Not a distinct ASP.NET Core feature — it’s claims + policies applied at action-level granularity.
• Best for systems needing fine-grained access control (e.g., admin dashboards, multi-tenant SaaS apps) where roles alone would multiply out of control.
• Often combined with a dynamic IAuthorizationPolicyProvider so you don’t have to manually register hundreds of policies.
• Roles can still exist as a UI/management convenience (grouping permissions), while actual authorization decisions are made on permissions.

62. How does JWT authentication work and explain it’s three parts ?

JWT authentication is a stateless authentication mechanism where, after a user logs in with valid credentials, the server generates a signed JSON Web Token (JWT) containing the user’s identity and claims, and sends it back to the client. The client then includes this token in the Authorization: Bearer <token> header on every subsequent request, and the server simply verifies the token’s signature and expiration to authenticate the user — without needing to query a database or maintain session state. Since the token itself carries all the necessary user information and is cryptographically signed (though not encrypted) to prevent tampering, JWT authentication scales well for distributed systems and APIs, such as those built with ASP.NET Core, where multiple servers can validate tokens independently without shared session storage.

How it works:

1. User logs in with credentials (username/password).
2. Server validates credentials and generates a JWT (JSON Web Token), signed with a secret/private key.
3. Server sends the token back to the client.
4. Client stores the token (e.g., in memory, localStorage) and sends it in the Authorization: Bearer <token> header on every subsequent request.
5. Server verifies the token’s signature and expiry on each request — no database/session lookup needed — and extracts claims to identify/authorize the user.

Three parts (separated by dots: header.payload.signature):

Example: eyJhbGciOi... (header) .eyJzdWIiOi... (payload) .SflKxwRJ... (signature)

Since the signature guarantees integrity (not secrecy — payload is just Base64-encoded, not encrypted), JWTs enable stateless authentication.

63. Why must UseAuthentication() come before UseAuthorization() ?

Because authorization depends on the result of authentication. Middleware runs in the order it’s registered, and:

• UseAuthentication() identifies who the user is — it reads the request (e.g., cookie, JWT token), validates it, and populates HttpContext.User with a ClaimsPrincipal.
• UseAuthorization() decides what that user is allowed to do — it checks roles/claims/policies against HttpContext.User.

If UseAuthorization() ran first, HttpContext.User would still be an empty/unauthenticated principal (no claims set), so every authorization check would fail — even for legitimately authenticated users — because there’d be no identity to evaluate yet.

app.UseAuthentication(); // Sets HttpContext.User
app.UseAuthorization();  // Checks HttpContext.User against policies/roles

In short: Authorization needs a populated User to check against — and only authentication middleware populates it. Wrong order → authorization always fails.

64. What is OpenID Connect ?

OpenID Connect is an authentication protocol built on top of OAuth 2.0. While OAuth 2.0 is designed for authorization (granting access to resources), OIDC adds an identity layer on top of it, allowing clients to verify the identity of a user and obtain basic profile information.

Key Points:

• Authentication, not just authorization: OAuth 2.0 tells you “this app has permission to access X,” but it doesn’t tell you who the user is. OIDC solves this by introducing the concept of an ID Token.
• ID Token: A JSON Web Token (JWT) issued by the identity provider (IdP) after successful authentication. It contains claims about the user (e.g., sub, name, email, iat, exp) that the client application can verify and trust.
• Standardized flow: Uses the same flows as OAuth 2.0 (Authorization Code, Implicit, etc.), but the token response includes both an access token (for authorization) and an ID token (for authentication).

How it Works (Simplified Flow):

1. The client redirects the user to the Identity Provider (e.g., IdentityServer, Azure AD, Google).
2. The user authenticates (logs in) with the IdP.
3. The IdP redirects back to the client with an authorization code.
4. The client exchanges the code for an access token and an ID token.
5. The client validates the ID token’s signature, issuer, audience, and expiry.
6. The client extracts user claims from the ID token to establish the user’s identity.

Example in ASP.NET Core:

builder.Services.AddAuthentication(options =>
{
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = "oidc";
})
.AddCookie(CookieAuthenticationDefaults.AuthenticationScheme)
.AddOpenIdConnect("oidc", options =>
{
    options.Authority = "https://your-identity-provider.com";
    options.ClientId = "your-client-id";
    options.ClientSecret = "your-client-secret";
    options.ResponseType = "code";
    options.SaveTokens = true;
    options.Scope.Add("openid");
    options.Scope.Add("profile");
});

65. What is OAuth 2.0 ? What is the difference between OAuth 2.0 and OpenID Connect ?

OAuth 2.0 is an authorization framework (protocol) that allows a third-party application to obtain limited access to a user’s resources on another service, without exposing the user’s credentials (like username/password) to that third-party application.

Key Idea:

Instead of giving your password to an app, you grant it a token that allows limited, specific access — for a limited time — to your data hosted on another service.

Example: You want a photo-printing app to access your Google Photos. Instead of giving the app your Google password, Google issues an access token that only allows access to your photos, nothing else (not your emails, contacts, etc.).

Key Roles in OAuth 2.0:

Key Concepts:

• Access Token: A credential (often a JWT or opaque string) used by the client to access protected resources. It has a limited lifetime and scope.
• Refresh Token: Used to obtain a new access token once the current one expires, without requiring the user to log in again.
• Scope: Defines the level/boundary of access requested (e.g., read:photos, write:contacts).
• Grant Type: The method by which the client obtains an access token.

Common OAuth 2.0 Grant Types (Flows):

OIDC vs OAuth 2.0

Common Claims in an ID Token

• sub — unique identifier for the user
• iss — issuer (the identity provider)
• aud — audience (the client app)
• exp — expiration time
• iat — issued at time
• name, email, email_verified — profile information (if requested via scopes)

In short: OIDC = OAuth 2.0 + Identity. It’s the standard way to implement “Login with Google/Microsoft/Facebook” style authentication in modern applications, including ASP.NET Core apps using AddOpenIdConnect() or integrating with IdentityServer/Duende IdentityServer.

Duende IdentityServer

Duende IdentityServer questions are important to prepare for in ASP.NET Core interviews because authentication and authorization are core concerns in almost every real-world enterprise application, and Duende IdentityServer is the de facto standard for implementing centralized identity management, SSO, and API security in the .NET ecosystem — so interviewers use it to gauge whether you truly understand OAuth 2.0 and OpenID Connect concepts in practice, not just in theory. Many companies have existing systems built on IdentityServer4 or are migrating to Duende IdentityServer, so employers want to confirm you can configure clients, scopes, resources, and grant types, handle token issuance and validation, integrate custom user stores, and troubleshoot common issues like token expiration, CORS, or redirect URI mismatches — all of which reflect real production challenges. Additionally, since security vulnerabilities in authentication systems can have severe consequences, interviewers use these questions to assess whether a candidate has the judgment and depth needed to design and maintain a secure, standards-compliant identity solution rather than just copy-pasting configuration code, making this topic a strong signal of a candidate’s practical, production-ready expertise versus surface-level knowledge.

66. What is Duende Software IdentityServer ?

Duende IdentityServer is a commercial, open-source OpenID Connect and OAuth 2.0 framework for .NET, used to build a centralized authentication and authorization server (also called a Security Token Service / STS) in ASP.NET Core applications. It is the officially supported successor to IdentityServer4, developed by Duende Software after the original creators discontinued free maintenance of IdentityServer4.

Why It Exists:

In enterprise applications, you often have multiple client applications (web apps, SPAs, mobile apps) and multiple APIs that all need to authenticate users and authorize access consistently. Instead of each app implementing its own login and token logic, Duende IdentityServer centralizes this into one identity provider that all apps trust.

What It Does:

Key Building Blocks (Configuration Concepts):

• Clients — the applications allowed to request tokens (e.g., a web app, a mobile app)
• Scopes — what the client is allowed to request (openid, profile, api1.read)
• Resources — APIs or identity data being protected
• Grant Types — flow used to get a token (Authorization Code + PKCE is the modern standard)

Example: Minimal Setup in ASP.NET Core

builder.Services.AddIdentityServer()
    .AddInMemoryClients(Config.Clients)
    .AddInMemoryApiScopes(Config.ApiScopes)
    .AddInMemoryIdentityResources(Config.IdentityResources)
    .AddTestUsers(Config.Users); // or AddAspNetIdentity<ApplicationUser>()

app.UseIdentityServer();

A client app then consumes it like this:

.AddOpenIdConnect("oidc", options =>
{
    options.Authority = "https://your-duende-identityserver.com";
    options.ClientId = "webapp-client";
    options.ResponseType = "code";
});

Why Interviewers Ask This

1. Tests real-world knowledge — most companies don’t build raw OAuth/OIDC flows manually; they use a framework like this, so interviewers want to know if you’ve actually implemented it.
2. Checks migration awareness — since IdentityServer4 is deprecated (EOL Nov 2022), interviewers want to know if you’re aware of the shift to Duende IdentityServer and its licensing change (free for dev/small-scale, paid for production at scale).
3. Assesses architecture understanding — configuring Clients, Scopes, and Resources correctly requires understanding the full OAuth2/OIDC flow, not just theory.
4. Security depth — token validation, secure redirect URIs, and grant type selection are common real-world pitfalls; this question filters candidates who understand why, not just how.

67. What is an API scope ? What is an API resource ?

These two concepts are often confused but serve different purposes in modeling what a client can access.

API Resource:

An API Resource represents the actual API/application you want to protect — a logical grouping of one or more related APIs that validate tokens.

• Think of it as the “owner” or “container” for one or more scopes.
• It typically corresponds to a physical API (e.g., OrdersApi, PaymentsApi).
• A single API Resource can expose multiple scopes.
• Access tokens are validated against the API Resource (via its name or associated scopes), and the API checks the token’s aud (audience) / scope claims.

new ApiResource("orders-api", "Orders API")
{
    Scopes = { "orders.read", "orders.write" }
}

API Scope

An API Scope represents a specific permission or capability that a client can request — a granular piece of access within an API Resource.

• It’s what actually appears in the access token’s scope claim.
• Clients request specific scopes; the API checks if the token contains the required scope before allowing an operation.
• Naming convention is often resource.action, like orders.read, orders.write, payments.refund.

new ApiScope("orders.read", "Read access to Orders"),
new ApiScope("orders.write", "Write access to Orders")

How They Relate:

API Resource: "orders-api"
   ├── Scope: "orders.read"
   └── Scope: "orders.write"

• A client requests one or more scopes (orders.read).
• The Authorization Server (e.g., Duende IdentityServer) checks if the client is allowed those scopes, then issues an access token containing them.
• The API Resource (orders-api) validates the incoming token — checking that the token’s audience/scopes match what it expects.

Example in Duende IdentityServer Config

public static IEnumerable<ApiScope> ApiScopes =>
    new List<ApiScope>
    {
        new ApiScope("orders.read", "Read Orders"),
        new ApiScope("orders.write", "Write Orders")
    };

public static IEnumerable<ApiResource> ApiResources =>
    new List<ApiResource>
    {
        new ApiResource("orders-api", "Orders API")
        {
            Scopes = { "orders.read", "orders.write" }
        }
    };

68. What is a client in IdentityServer ? What is a client ID and client secret ?

A Client in IdentityServer (Duende IdentityServer) represents an application that is registered to request tokens from the IdentityServer — i.e., anything that wants to authenticate a user or get access to an API on behalf of a user (or itself) must be configured as a Client.

• Examples of clients: a web app, a mobile app, a SPA, a backend service (M2M).
• Each client has its own configuration defining what it’s allowed to do — which grant types it can use, which scopes it can request, where it can redirect to after login, token lifetimes, etc.

Example:

new Client
{
    ClientId = "webapp-client",
    ClientSecrets = { new Secret("supersecret".Sha256()) },
    AllowedGrantTypes = GrantTypes.Code,
    RedirectUris = { "https://myapp.com/signin-oidc" },
    AllowedScopes = { "openid", "profile", "orders.read" },
    RequirePkce = true
}

Client ID

The Client ID is a public, unique identifier for the client application registered with the IdentityServer.

• Think of it like a username for the application (not secret — it’s often visible in browser URLs, JS code, mobile app binaries).
• IdentityServer uses it to look up the client’s configuration (allowed scopes, grant types, redirect URIs, etc.) when a token request comes in.

ClientId = "webapp-client"

Client Secret

The Client Secret is a confidential credential (like a password) that proves the client’s identity to the IdentityServer — used only by confidential clients (server-side apps that can safely store secrets).

• It’s exchanged along with the Client ID when requesting a token, so IdentityServer can verify the request is genuinely coming from that registered client (not an impersonator).
• Never used in public clients like SPAs or mobile apps, since those can’t securely store a secret (anyone could extract it from client-side code) — that’s why PKCE replaces the need for a client secret in public clients.

ClientSecrets = { new Secret("supersecret".Sha256()) }

Think of Client ID as a username and Client Secret as a password — but for an application, not a human user. Just like a user proves who they are with a username/password, a confidential client app proves its identity to IdentityServer with a Client ID/Client Secret pair before it’s trusted to receive tokens.

69. What is an identity resource ?

An Identity Resource in IdentityServer (OIDC) represents a set of claims about a user’s identity — such as their name, email, or profile info — that a client can request access to via scopes. While API Resources/Scopes control access to APIs, Identity Resources control access to user identity data returned in the ID Token.

Why It Exists

When a client authenticates a user via OpenID Connect, it doesn’t just want a plain “yes, logged in” — it usually wants some information about the user (name, email, etc.). Identity Resources define exactly which claims get bundled together and exposed as a requestable scope.

Standard (Built-in) Identity Resources

IdentityServer ships with standard OIDC identity resources out of the box:

Custom Identity Resource Example

You can also define your own, e.g., to expose a custom role or department claim:

public static IEnumerable<IdentityResource> IdentityResources =>
    new List<IdentityResource>
    {
        new IdentityResources.OpenId(),
        new IdentityResources.Profile(),
        new IdentityResource(
            name: "roles",
            displayName: "User Roles",
            claimTypes: new[] { "role" })
    };

How It’s Used:

1. Client requests scopes including an identity resource: openid profile roles.
2. User logs in and consents.
3. IdentityServer issues an ID Token containing the claims tied to those identity resources (sub, name, role, etc.).
4. Client reads these claims to know who the user is.

AllowedScopes = { "openid", "profile", "roles", "orders.read" }

(Notice orders.read here is an API Scope, while openid, profile, roles are Identity Resources — both can be requested together in the same token request.)

70. What does the openid scope do ?

The openid scope is the switch that turns on OpenID Connect authentication — it’s mandatory for any login flow, triggers the issuance of an ID Token, and adds the sub claim (unique user identifier) to that token. Without it, you’re doing plain OAuth 2.0 authorization with no guaranteed identity information.

What It Actually Does

1. Activates OIDC behavior — without openid, the request is treated as plain OAuth 2.0 (authorization only). Including it tells IdentityServer: “This is an OpenID Connect request — I need to know who the user is, not just what they can access.”
2. Triggers ID Token issuance — when openid is requested (and the flow completes), the token response includes an ID Token (a JWT) alongside any access token.
3. Includes the sub claim — the openid scope maps to the IdentityResources.OpenId identity resource, which contains exactly one claim: sub (subject identifier — a unique, stable ID for the authenticated user).

71. What does the profile scope do ?

The profile scope is a standard Identity Resource that bundles general user profile claims (name, given_name, picture, etc.) into the ID Token — but it only returns claims that are actually populated for the user via your IProfileService or identity store.

What It Adds

When a client includes profile in its scope request (alongside the mandatory openid), IdentityServer includes these claims in the ID Token (or makes them available via the /connect/userinfo endpoint), if the user has values for them:

72. What is the sub claim ?

The sub (subject) claim is the unique, stable identifier for the authenticated user — it’s the single most important claim in OpenID Connect, and the only claim guaranteed to be present whenever the openid scope is requested.

What It Represents:

• sub answers the question: “Which user is this, exactly?”
• It’s typically a unique ID from the identity provider’s user store (e.g., a GUID or primary key), not the user’s email or username — because emails/usernames can change, but sub must remain constant for the lifetime of that user’s account.

{
  "sub": "8f14e45f-ceea-467a-9575-9a61a1c8b1c5",
  "name": "John Doe",
  "email": "john@example.com"
}

Why It Matters:

1. Primary key for identity — your application should use sub (not email or name) as the key to look up/link the local user record, since it’s immutable and unique.
2. Guaranteed presence — every ID Token issued for an openid scope request contains sub, even if no other claims are requested.
3. Uniqueness scope — sub is guaranteed unique within the issuer (iss) — i.e., unique per identity provider. The combination of iss + sub is what truly guarantees global uniqueness (important when supporting multiple identity providers/federation).

73. What is a signing credential ?

A Signing Credential is the cryptographic key (and algorithm) that IdentityServer (or any OIDC/OAuth token issuer) uses to digitally sign the tokens it issues — primarily the ID Token and, optionally, the Access Token (when using JWT format). It’s what allows clients and APIs to verify that a token is genuine and hasn’t been tampered with.

Why It’s Needed

Tokens (JWTs) are just Base64-encoded JSON — anyone can read or even forge one if there’s no way to verify authenticity. The signing credential solves this: IdentityServer signs the token with a private key, and consumers (clients/APIs) verify the signature using the corresponding public key — proving the token really came from that trusted issuer and wasn’t altered in transit.

How It Works (Simplified)

1. IdentityServer creates a token (header + payload).
2. It signs the token using its private key → produces the token’s signature.
3. The signed JWT (header.payload.signature) is sent to the client.
4. The client/API fetches IdentityServer’s public key (via the discovery/JWKS endpoint) and verifies the signature.
5. If the signature is valid → token is trusted, unmodified, and genuinely issued by that server.

JWT = Base64(Header) + "." + Base64(Payload) + "." + Signature
Signature = Sign(Header + Payload, PrivateKey)

74. What is AddDeveloperSigningCredential() ? Why should developer signing credentials not be used in production ?

AddDeveloperSigningCredential() is a convenience method in Duende IdentityServer used to quickly generate a temporary RSA signing key for local development and testing, so you don’t have to set up a real X.509 certificate just to get IdentityServer running.

builder.Services.AddIdentityServer()
    .AddDeveloperSigningCredential();

What It Actually Does

1. On first run, it generates an RSA key pair and serializes it to a file on disk (typically tempkey.rsa or tempkey.jwk in the app’s root directory).
2. On subsequent runs, it reuses the same key from that file (so tokens remain valid across restarts during development, as long as the file persists).
3. This key is used to sign ID Tokens and JWT access tokens, just like a “real” signing credential would.

Why It Must NOT Be Used in Production

a. Key Is Not Securely Managed

The key is stored as a plain file on the local disk of the server — no encryption, no access control, no integration with a proper secrets/key management system (like Azure Key Vault, AWS KMS, or an HSM). Anyone with file system access can read the private key and forge valid tokens.

b. Not Portable Across Multiple Instances/Servers

In production, you typically run multiple instances of your app (load-balanced, containerized, auto-scaled). Since the key file is generated locally per instance, each instance would have a different signing key — meaning a token issued by Instance A would fail validation when checked against Instance B’s public key. This breaks authentication in any horizontally-scaled deployment.

Instance A (Key A) → issues token → 
Instance B (Key B) → tries to validate → ❌ Signature mismatch

c. Key Regeneration Invalidates Existing Tokens

If the key file is lost, deleted, or the app is redeployed to a fresh container/environment without persisting that file (very common in containerized/cloud deployments), a new key is generated — instantly invalidating all previously issued tokens. Users get logged out unexpectedly; APIs start rejecting valid-looking tokens.

d. No Key Rotation Support

Production systems need key rotation (periodically retiring old keys while still honoring recently-issued tokens signed with them, using multiple keys in the JWKS). AddDeveloperSigningCredential() has no concept of rotation — it’s a single, static key with no lifecycle management.

e. Security/Compliance Red Flag

Using a developer-only feature in production is a clear signal of misconfiguration — it may fail security audits/pen tests outright, since the key isn’t protected by any real key management or rotation policy.

What to Use Instead in Production

75. What is tempkey.jwk ?

tempkey.jwk is the physical JSON file where AddDeveloperSigningCredential() stores its auto-generated RSA private/public key pair on disk — convenient for local development, but a common source of production bugs (like users getting logged out on every deploy) since it’s not portable, persistent, or securely managed across multiple instances.

What’s Inside It:

The file contains a serialized JWK (JSON Web Key) — a standard JSON format for representing a cryptographic key. It holds the RSA private key (and its corresponding public key components) that IdentityServer uses to sign tokens.

{
  "kty": "RSA",
  "kid": "a3f8c9e2b1d4...",
  "use": "sig",
  "alg": "RS256",
  "n": "xGOr-H7A-PWc7uxi...",   // modulus (part of public key)
  "e": "AQAB",                  // exponent (part of public key)
  "d": "X4cTteJY_gn4FYPsXB8r...", // private exponent — THE SECRET
  "p": "...", "q": "...", "dp": "...", "dq": "...", "qi": "..."  // other RSA private key components
}

• kty — key type (RSA)
• kid — key ID (used to match the right key when multiple keys exist)
• alg — signing algorithm (RS256)
• n, e — the public key components (safe to share)
• d, p, q, etc. — the private key components (must stay secret — this is what signs tokens)

76. What is the difference between an Access token and Refresh token ?

Both are issued by the Authorization Server, but they serve completely different purposes in the OAuth 2.0 flow — one is for using an API, the other is for getting new access without re-login.

Access Token

The Access Token is the credential a client presents to a Resource Server (API) to access protected resources.

• Purpose: Authorization — proves the client has permission to call the API with certain scopes.
• Lifetime: Short-lived (typically minutes to a few hours) — by design, to limit damage if it’s leaked/stolen.
• Sent to: Resource Server / API (in the Authorization: Bearer <token> header).
• Format: Can be a JWT (self-contained, verifiable via signature) or an opaque/reference token (API must call back to the Authorization Server to validate it via introspection).
• Contains: Scopes, expiry (exp), issuer (iss), audience (aud), and sometimes user claims.

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6...

Refresh Token

The Refresh Token is a long-lived credential used only to obtain a new Access Token (and often a new Refresh Token) once the current Access Token expires — without requiring the user to log in again.

• Purpose: Session continuity — silent renewal of access.
• Lifetime: Long-lived (days, weeks, or even until explicitly revoked).
• Sent to: Only the Authorization Server’s token endpoint — never sent to APIs/Resource Servers.
• Format: Almost always opaque (a random string) — not meant to be decoded/inspected by clients.
• Higher sensitivity: Since it can generate new access indefinitely, it must be stored very securely (e.g., HTTP-only secure cookie or server-side storage — never in browser localStorage for SPAs).

POST /connect/token
grant_type=refresh_token
&refresh_token=8xLOxBtZp8...
&client_id=webapp-client
&client_secret=...

Why Have Both?

This two-token design balances security and user experience:

• Short-lived Access Tokens minimize the attack window if intercepted.
• Long-lived Refresh Tokens avoid forcing users to log in every few minutes, while still letting the Authorization Server revoke access at any time (e.g., on logout, password change, or suspicious activity) by invalidating the refresh token — which immediately stops any further access token renewal.

ASP.NET CORE Performance based Interview Questions

ASP.NET Core performance-based interview questions matter because performance problems are among the most common and costly issues in production systems, and these questions reveal whether a candidate truly understands why the framework behaves the way it does — not just how to write functionally correct code. Topics like avoiding blocking async calls, caching (in-memory/distributed), efficient EF Core usage (AsNoTracking(), avoiding N+1 queries), and memory/GC awareness reflect real bottlenecks that only surface under actual load. A candidate who can reason about these trade-offs likely has hands-on experience diagnosing slow endpoints or memory issues in a live system — which is why employers use these questions as a strong signal of production readiness, not just theoretical knowledge.

77. What is caching ? What caching mechanisms are available in ASP.NET Core ?

Caching is the practice of storing frequently accessed or expensive-to-compute data in a temporary, fast-access storage layer, so subsequent requests for that same data can be served quickly — without repeating the expensive operation (e.g., a database query, an API call, or heavy computation).

Why It Matters:

• Reduces latency (faster response times)
• Reduces load on databases/downstream services
• Improves scalability — the same server can handle more requests
• Trade-off: cached data can become stale, so cache invalidation/expiration strategy matters

Caching Mechanisms in ASP.NET Core

a. In-Memory Caching (IMemoryCache)

Stores data in the web server’s own process memory. Fast, but not shared across multiple server instances.

builder.Services.AddMemoryCache();

public class ProductService
{
    private readonly IMemoryCache _cache;
    public ProductService(IMemoryCache cache) => _cache = cache;

    public Product GetProduct(int id)
    {
        return _cache.GetOrCreate($"product_{id}", entry =>
        {
            entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10);
            return _repository.GetById(id); // expensive call, only runs on cache miss
        });
    }
}

Best for: single-server apps, or data that’s okay to differ slightly between instances.

b. Distributed Caching (IDistributedCache)

Stores data in an external, shared cache (e.g., Redis, SQL Server) — consistent across multiple server instances (critical for load-balanced/scaled-out apps).

builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = "localhost:6379";
});

public async Task<string> GetDataAsync(string key)
{
    var cached = await _distributedCache.GetStringAsync(key);
    if (cached != null) return cached;

    var data = await FetchExpensiveDataAsync();
    await _distributedCache.SetStringAsync(key, data,
        new DistributedCacheEntryOptions { AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10) });
    return data;
}

Best for: multi-server/cloud deployments where all instances must see the same cached data.

c. Response Caching (Response Caching Middleware)

Caches the entire HTTP response (based on headers like Cache-Control), so identical requests are served directly — often from the client/browser or a proxy — without hitting the server logic at all.

builder.Services.AddResponseCaching();
app.UseResponseCaching();

[HttpGet]
[ResponseCache(Duration = 60)]
public IActionResult GetProducts() => Ok(_products);

Best for: public, non-personalized GET endpoints (e.g., product listings).

d. Output Caching (ASP.NET Core 7+)

A newer, more flexible server-side caching mechanism than Response Caching — supports tag-based invalidation, policies, and varying by query string/headers, without relying solely on HTTP cache headers.

builder.Services.AddOutputCache(options =>
{
    options.AddPolicy("Expire60", b => b.Expire(TimeSpan.FromSeconds(60)));
});
app.UseOutputCache();

app.MapGet("/products", GetProducts).CacheOutput("Expire60");

Best for: modern apps needing fine-grained control (tag invalidation, per-endpoint policies) — generally preferred over Response Caching in .NET 7+.

Quick Comparison:

Why Interviewers Ask This:

1. Tests whether you know when to use which — a very common real-world mistake is using IMemoryCache in a load-balanced multi-instance deployment, causing inconsistent data across servers.
2. Checks awareness of cache invalidation challenges — “there are only two hard problems in computer science: cache invalidation and naming things.”
3. Follow-up likely: “How would you handle cache invalidation when the underlying data changes?” → Explicitly remove/update the cache entry on write (Cache-Aside pattern), or use short expiration + tag-based invalidation (Output Caching supports this natively).

78. When should you use Redis ?

Redis is an in-memory, distributed data store — use it when you need fast, shared state across multiple servers/instances, which IMemoryCache alone can’t provide.

Key Scenarios:

When NOT to Use Redis:

• Single-instance apps — IMemoryCache is simpler and faster (no network hop).
• Long-term persistent storage — Redis is primarily in-memory; not a replacement for a relational/durable database (though it supports optional persistence).
• Complex relational queries — Redis is a key-value store, not suited for relational joins/reporting.

Why Interviewers Ask This:

Tests whether you understand the actual problem Redis solves — shared, fast state across a distributed system — rather than just knowing “Redis = caching.” A common follow-up: “Why not just use IMemoryCache everywhere?” → Because in a scaled-out deployment, each instance would have its own separate cache, causing inconsistent data (e.g., a user’s session existing on Server A but not Server B).

In short: Use Redis when you need fast, shared state across multiple app instances — distributed caching, centralized session storage, SignalR backplane, or atomic counters — not for single-server apps or as a primary relational database.

79. What is cache invalidation ? What is cache stampede ?

Cache invalidation is explicitly clearing/updating stale cache data when the source changes (via TTL, cache-aside, or write-through). Cache stampede is when many concurrent requests simultaneously regenerate the same expired cache entry, overwhelming the backend — prevented via locking, background refresh, or staggered expiration.

80. How can caching improves performance ?

Caching improves performance by avoiding repeated, expensive work — serving data from a fast storage layer instead of recomputing or re-fetching it every time.

Key Ways It Helps:

Example:

// Without caching: every request hits the database
public Product GetProduct(int id) => _repository.GetById(id); // DB call every time

// With caching: DB is hit once, then served from memory
public Product GetProduct(int id) =>
    _cache.GetOrCreate($"product_{id}", entry =>
    {
        entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10);
        return _repository.GetById(id); // only runs on cache miss
    });

If this endpoint gets 10,000 requests in 10 minutes for the same product, without caching that’s 10,000 database queries; with caching, it’s just 1 database query — the rest are served instantly from memory.

Where It Matters Most:

• Read-heavy, rarely-changing data (product catalogs, configuration, reference data) — biggest win
• Expensive computations (reports, aggregations) — cache the result, not just raw data
• External API calls — especially rate-limited or slow third-party services

The Trade-off:

Caching trades freshness for speed — cached data can become stale until it’s invalidated/expired, so it’s best suited for data that doesn’t need to be instantly up-to-date on every single request.

81. What is rate limiting ? Why would you use rate limiting in an API ? What HTTP status code is normally returned when rate limiting rejects a request?

Rate limiting is a technique used to control how many requests a client (identified by IP, user, API key, etc.) can make to an API within a given time window — rejecting or delaying requests that exceed the allowed threshold.

Why Use Rate Limiting in an API?

HTTP Status Code

When a request is rejected due to rate limiting, the API should return:

429 Too Many Requests

This is the standard status code (RFC 6585) indicating the client has sent too many requests in a given time period. It’s common to also include a Retry-After header telling the client how long to wait before retrying.

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

{
  "error": "Rate limit exceeded. Try again in 30 seconds."
}

Example in ASP.NET Core (Built-in Rate Limiting Middleware, .NET 7+)

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("fixed", opt =>
    {
        opt.PermitLimit = 100;
        opt.Window = TimeSpan.FromMinutes(1);
        opt.QueueLimit = 0; // no queueing, reject immediately over limit
    });

    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
});

app.UseRateLimiter();

app.MapGet("/api/data", () => "response")
   .RequireRateLimiting("fixed");

Why Interviewers Ask This:

1. Tests API design/security awareness — rate limiting is a fundamental protection mechanism that many junior developers overlook until an incident forces it.
2. Standards knowledge — knowing the correct status code (429, not 403 or 503) shows familiarity with HTTP semantics, not just “it returns an error.”
3. Follow-up likely: “What’s the difference between rate limiting and throttling?” → Rate limiting typically rejects excess requests outright (429), while throttling may delay/queue them to smooth out load instead of rejecting immediately — ASP.NET Core’s rate limiter supports both behaviors depending on configuration (e.g., QueueLimit > 0 allows queuing instead of immediate rejection).

82. What rate limiter algorithms are available in ASP.NET Core?

ASP.NET Core’s built-in Rate Limiting Middleware (introduced in .NET 7, via System.Threading.RateLimiting) provides four algorithms, each suited to different traffic patterns.

1. Fixed Window Limiter

Allows a fixed number of requests within a fixed time window (e.g., 100 requests per minute). Once the window resets, the count resets to zero.

options.AddFixedWindowLimiter("fixed", opt =>
{
    opt.PermitLimit = 100;
    opt.Window = TimeSpan.FromMinutes(1);
});

Drawback: Can allow bursts at window boundaries — e.g., 100 requests at 11:59:59 and another 100 at 12:00:00 = 200 requests in 1 second.

2. Sliding Window Limiter

Similar to Fixed Window, but divides the window into smaller segments, and the limit slides continuously — smoothing out the boundary-burst problem of Fixed Window.

options.AddSlidingWindowLimiter("sliding", opt =>
{
    opt.PermitLimit = 100;
    opt.Window = TimeSpan.FromMinutes(1);
    opt.SegmentsPerWindow = 4; // divides window into 4 segments of 15 sec each
});

Benefit: More accurate, fairer rate limiting than Fixed Window, at the cost of slightly more overhead/complexity.

3. Token Bucket Limiter

Maintains a “bucket” of tokens that refill at a steady rate up to a maximum capacity. Each request consumes a token; if the bucket is empty, the request is rejected. Allows controlled bursts as long as tokens are available.

options.AddTokenBucketLimiter("token", opt =>
{
    opt.TokenLimit = 100;
    opt.TokensPerPeriod = 20;
    opt.ReplenishmentPeriod = TimeSpan.FromSeconds(10);
    opt.QueueLimit = 0;
});

Best for: APIs that want to allow occasional bursts of traffic while maintaining a steady average rate over time.

4. Concurrency Limiter

Limits the number of simultaneous/concurrent requests being processed, rather than counting requests over time. Once a request finishes, a “slot” frees up for the next one.

options.AddConcurrencyLimiter("concurrency", opt =>
{
    opt.PermitLimit = 10; // max 10 concurrent requests
    opt.QueueLimit = 5;   // up to 5 requests can queue and wait
});

Best for: Protecting resource-intensive endpoints (e.g., heavy computation, file processing) where the concern is simultaneous load, not total request count over time.

83. What is OnRejected ? What is Retry-After ?

OnRejected is a callback delegate in ASP.NET Core’s Rate Limiting Middleware that gets executed whenever a request is rejected because it exceeded the configured rate limit. It lets you customize what happens on rejection — instead of just relying on the default 429 response, you can add custom logging, headers, or a custom response body.

Why It’s Useful:

By default, a rejected request just returns a bare 429 Too Many Requests with no body. OnRejected lets you:

• Log rejected requests (for monitoring/alerting on abuse patterns)
• Return a custom error message/JSON body
• Add a Retry-After header to tell the client when to try again
• Track metrics (e.g., increment a counter for rate-limit violations)

Retry-After is a standard HTTP response header (defined in RFC 7231/9110) that tells the client how long to wait before making another request. It’s most commonly used alongside 429 Too Many Requests (rate limiting) and 503 Service Unavailable (temporary outages/maintenance).

Format:

It can be specified in two ways:

Retry-After: 30

→ Wait 30 seconds before retrying.

Retry-After: Wed, 21 Oct 2026 07:28:00 GMT

Retry-After: Wed, 21 Oct 2026 07:28:00 GMT

84. Where should rate limiting middleware be placed in the request pipeline ?

Rate limiting middleware should be placed early in the pipeline — after exception handling/HTTPS redirection, but before routing, authentication, and authorization — so excessive requests are rejected cheaply before consuming server resources, and sensitive endpoints like login remain protected from brute-force abuse.

var app = builder.Build();

app.UseExceptionHandler("/error");   // 1. Catch unhandled exceptions first
app.UseHttpsRedirection();            // 2. Enforce HTTPS early

app.UseRateLimiter();                 // 3. Rate limit BEFORE expensive work

app.UseRouting();                     // 4. Routing
app.UseAuthentication();              // 5. AuthN
app.UseAuthorization();               // 6. AuthZ

app.MapControllers()
   .RequireRateLimiting("fixed");     // can also apply per-endpoint

app.Run();

Why Place It Early?

1. Reject cheaply, before doing real work — the whole point of rate limiting is to protect resources. If it runs after authentication, database calls, or business logic, the server has already spent CPU/DB/network resources on a request it’s about to reject anyway — defeating the purpose.
2. Protects against unauthenticated abuse too — if placed after UseAuthentication(), an attacker flooding the login endpoint or public unauthenticated endpoints wouldn’t be rate-limited until after auth logic runs, which itself can be exploited (e.g., brute-force attacks, credential stuffing) for the very endpoints that most need protecting.
3. Consistent with .NET’s benchmark ordering guidance — Microsoft’s own recommended middleware order places rate limiting near the top, alongside exception handling and HTTPS redirection, and before routing/auth.

85. How do you improve ASP.NET Core API performance ?

This is a broad, common interview question testing whether you know performance optimization across the full stack — not just one trick. Structure your answer around key areas:

1. Asynchronous Programming

Avoid blocking calls (.Result, .Wait()) that tie up thread pool threads. Use async/await throughout the call chain for I/O-bound operations (DB calls, HTTP calls, file I/O).

// ❌ Blocks a thread pool thread
var data = _repository.GetDataAsync().Result;

// ✅ Frees the thread while waiting
var data = await _repository.GetDataAsync();

2. Caching

Reduce repeated expensive work using IMemoryCache (single instance) or IDistributedCache/Redis (multi-instance), plus Output Caching for full response caching.

3. Efficient Database Access (EF Core)

4. Response Compression

Reduces payload size over the network.

5. Minimize Middleware Pipeline Overhead

Keep the middleware pipeline lean — remove unused middleware, order it efficiently (put cheap/rejecting middleware like rate limiting early).

6. Use Minimal APIs Where Appropriate

Minimal APIs have less overhead than full MVC controllers for simple endpoints, due to a lighter execution pipeline.

8. Pagination & Limiting Payload Size

Never return unbounded result sets — paginate large collections to reduce response size and DB load.

var results = await _context.Products
    .Skip((page - 1) * pageSize)
    .Take(pageSize)
    .ToListAsync();

9. HTTP Client Best Practices

Use IHttpClientFactory (avoids socket exhaustion from creating raw HttpClient instances) and configure connection pooling/timeouts properly.

10. Rate Limiting & Load Shedding

Prevent overload from excessive/abusive traffic (covered earlier) — protects the API from degrading under unexpected spikes.

11. Kestrel & Hosting Configuration

• Tune Kestrel limits (max concurrent connections, request body size).
• Run behind a reverse proxy (e.g., YARP, Nginx) with proper load balancing.
• Enable HTTP/2 or HTTP/3 for multiplexed connections where applicable.

12. Monitoring & Profiling

Use Application Insights, dotnet-trace, MiniProfiler, or BenchmarkDotNet to identify actual bottlenecks — optimize based on data, not guesses.

Why Interviewers Ask This:

1. Tests breadth of practical knowledge — performance issues can come from many layers (code, database, network, infrastructure); a strong candidate can reason across all of them.
2. Real-world signal — this question separates candidates who’ve actually debugged production performance issues from those who’ve only worked on small, low-traffic apps.
3. Follow-up likely: “What tools would you use to actually find the bottleneck before optimizing?” → Always measure first — use profiling/APM tools (Application Insights, dotnet-trace, BenchmarkDotNet) to identify the real bottleneck rather than guessing and optimizing the wrong thing.

86. Why is asynchronous programming important ?

Asynchronous programming is important because it allows the server to handle many concurrent requests efficiently, without wasting threads sitting idle while waiting on slow I/O operations (database calls, HTTP requests, file access).

The Core Problem It Solves:

ASP.NET Core uses a limited thread pool to handle incoming requests. If a request performs a blocking (synchronous) I/O call, the thread handling it sits idle, doing nothing but waiting — yet it’s still “busy” from the thread pool’s perspective, unavailable to serve other incoming requests.

// ❌ Synchronous/blocking: thread is stuck waiting for the DB
public IActionResult GetProduct(int id)
{
    var product = _repository.GetById(id); // blocks the thread
    return Ok(product);
}

With async/await, the thread is released back to the thread pool while waiting for the I/O operation to complete, and only resumes execution when the result is ready — meaning that same thread can serve other requests in the meantime.

// ✅ Asynchronous: thread is freed during the wait
public async Task<IActionResult> GetProduct(int id)
{
    var product = await _repository.GetByIdAsync(id); // thread returns to pool while waiting
    return Ok(product);
}

Why This Matters for Scalability:

Under high traffic, synchronous I/O-bound code can exhaust the thread pool — all threads get stuck waiting on slow database/network calls, and new incoming requests have no thread available to even start processing, causing timeouts and cascading failures. Asynchronous code avoids this by freeing threads during waits, letting a small number of threads efficiently serve a much larger number of concurrent requests.

87. What is the difference between Task, ValueTask, and void ?

Task, ValueTask, and void are all related to how a method represents its completion, but they serve very different purposes. This is particularly important when writing asynchronous code in ASP.NET Core.

1. Task

Task represents an asynchronous operation that will complete in the future. It is the most common return type for asynchronous methods in ASP.NET Core.

public async Task GetDataAsync()
{
    await Task.Delay(1000);
}

When a value needs to be returned, use Task<T>:

public async Task<string> GetNameAsync()
{
    await Task.Delay(1000);
    return "John";
}

The caller can use await to asynchronously wait for completion:

string name = await GetNameAsync();

Interview point: Task is the default choice for most asynchronous methods in ASP.NET Core.

2. ValueTask

ValueTask also represents an asynchronous operation, but it is designed for scenarios where an operation frequently completes synchronously.

public ValueTask<string> GetNameAsync()
{
    return ValueTask.FromResult("John");
}

The caller can still use await:

string name = await GetNameAsync();

The main advantage of ValueTask is that it can sometimes avoid allocating a new Task when the result is already available.

However, ValueTask is not automatically better than Task. It has additional usage restrictions and can make code more complicated. Therefore, use it primarily when performance measurements show that avoiding Task allocations is beneficial.

3. void

void means that the method does not return a value and does not represent an asynchronous operation.

public void SaveData()
{
    // Synchronous operation
}

You can technically declare an async void method:

public async void ProcessDataAsync()
{
    await Task.Delay(1000);
}

But async void should generally be avoided in ASP.NET Core application code.

Unlike Task, an async void method cannot be awaited by its caller:

ProcessDataAsync();
// Caller cannot await it

This makes it difficult to determine when the operation has finished and makes exception handling more difficult.

async void is mainly appropriate for event handlers, where the event pattern requires a void return type.

88. What causes thread-pool starvation ?

Thread-Pool starvation occurs when Thread Pool threads are occupied or blocked for too long, leaving insufficient threads to process incoming work. Common causes include synchronous blocking of asynchronous operations using .Result or .Wait(), Thread.Sleep, synchronous I/O, excessive CPU-bound work, and lock contention. In ASP.NET Core, it can result in increased latency, low throughput, and request timeouts. The primary solution is to use asynchronous, non-blocking APIs and avoid blocking Thread Pool threads.

89. How can database queries affect API performance ?

Database queries directly affect API performance because database operations are often a significant part of an API request’s response time. Slow queries, missing indexes, excessive data retrieval, N+1 queries, unnecessary round trips, and large result sets can increase latency and resource consumption. In ASP.NET Core, we can improve performance by using asynchronous database operations, proper indexing, projections, pagination, AsNoTracking() for suitable read-only queries, avoiding N+1 queries, and caching frequently accessed data.

How to improve database-related API performance?

Common techniques include:

• Use indexes appropriately.
• Use async database operations.
• Select only the required columns.
• Use pagination for large datasets.
• Avoid the N+1 query problem.
• Reduce unnecessary database round trips.
• Use AsNoTracking() for suitable read-only EF Core queries.
• Analyze slow queries using execution plans and database monitoring.
• Use caching where appropriate.
• Keep database transactions as short as practical.
• Avoid returning unnecessarily large datasets.

90. How can you reduce unnecessary database calls ?

To reduce unnecessary database calls, retrieve only the data required, avoid N+1 queries, batch operations, reuse data within a request, implement caching, use pagination and projections, and use AsNoTracking() for read-only EF Core queries. The goal is to minimize database round trips while ensuring that the queries that remain are efficient and properly indexed.

91. What is Response Compression in ASP.NET Core?

Response compression in ASP.NET Core is a middleware-based feature that compresses HTTP responses before sending them to clients. It reduces response size, saves bandwidth, and can improve network performance. ASP.NET Core supports compression algorithms such as Brotli and Gzip, and the middleware selects an appropriate encoding based on the client’s Accept-Encoding header.

92. What is Connection Pooling vs Object Pooling

Connection pooling reuses database connections to avoid the overhead of repeatedly establishing physical connections. Object pooling reuses application objects to reduce object allocation and initialization overhead. Connection pooling is primarily handled by the database provider, while object pooling can be explicitly implemented using mechanisms such as ASP.NET Core’s ObjectPool<T>.

93. How can you optimize large API responses ?

Large API responses can be optimized by using pagination, filtering, projection, DTOs, response compression, caching, and streaming for very large datasets. You should avoid returning unnecessary fields or deeply nested object graphs and retrieve only the data required by the client. The goal is to reduce database work, serialization overhead, memory consumption, and network bandwidth while keeping the API responsive.

94. What is pagination ? Why should APIs use pagination for large datasets ?

Pagination is the technique of dividing a large dataset into smaller, manageable portions called pages, instead of returning all records in a single API response.

For example, instead of returning 100,000 products at once, an API might return 20 or 50 products per request.

GET /api/products?page=1&pageSize=20

The client can then request the next page:

GET /api/products?page=2&pageSize=20

Example in ASP.NET Core

With Entity Framework Core:

var products = await db.Products
    .OrderBy(p => p.Id)
    .Skip((page - 1) * pageSize)
    .Take(pageSize)
    .ToListAsync();

Here:

• page specifies the requested page.
• pageSize specifies how many records to return.
• Skip() ignores records belonging to previous pages.
• Take() retrieves only the records required for the current page.

Why Should APIs Use Pagination?

1. Reduces Response Size

Instead of sending thousands of records, the API sends only a small subset.

Without pagination:
Database → 100,000 records → API → Client

With pagination:
Database → 50 records → API → Client

This reduces network bandwidth and response time.

2. Reduces Memory Usage

Loading a huge dataset into application memory can consume significant resources. Pagination keeps the amount of data processed at a time relatively small.

3. Improves Database Performance

The database doesn’t need to return the entire dataset for every request.

4. Improves API Response Time

Smaller responses generally mean faster database processing, serialization, network transfer, and client-side processing.

5. Improves User Experience

Clients can display the first page immediately rather than waiting for a massive response.

6. Prevents Resource Exhaustion

Without pagination, a poorly designed API could allow a request to retrieve millions of records, potentially consuming excessive CPU, memory, database connections, and network bandwidth.

Offset vs. Cursor Pagination

For simple APIs, offset pagination is common:

GET /api/products?page=5&pageSize=50

For very large or frequently changing datasets, cursor/keyset pagination can be more efficient because it avoids increasingly expensive large offsets.

For example:

GET /api/products?afterId=500&pageSize=50

Interview Answer

Pagination is the process of dividing a large dataset into smaller pages and returning only a limited number of records per API request. APIs should use pagination for large datasets because it reduces database workload, response size, network bandwidth, serialization time, and memory consumption. It also improves response time, scalability, and user experience. For very large datasets, cursor or keyset pagination can be preferable to traditional offset-based pagination.

In short: Pagination prevents an API from trying to return the entire database in a single response.

95. What is the difference between BackgroundService and IHostedService?

Both IHostedService and BackgroundService are used to run background tasks in ASP.NET Core applications. The key difference is that IHostedService is an interface, while BackgroundService is an abstract base class that implements IHostedService and provides a convenient structure for long-running background work.

IHostedService

IHostedService defines two methods:

public interface IHostedService
{
    Task StartAsync(CancellationToken cancellationToken);
    Task StopAsync(CancellationToken cancellationToken);
}

You implement these methods yourself:

public class MyHostedService : IHostedService
{
    public Task StartAsync(CancellationToken cancellationToken)
    {
        // Start background work
        return Task.CompletedTask;
    }

    public Task StopAsync(CancellationToken cancellationToken)
    {
        // Cleanup
        return Task.CompletedTask;
    }
}

It gives you complete control over how the service starts, runs, and stops.

BackgroundService

BackgroundService is an abstract class that implements IHostedService and provides an ExecuteAsync() method specifically designed for long-running background operations.

public class MyBackgroundService : BackgroundService
{
    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            // Do background work

            await Task.Delay(
                TimeSpan.FromSeconds(10),
                stoppingToken);
        }
    }
}

Register it with dependency injection:

builder.Services.AddHostedService<MyBackgroundService>();

Key Differences

When should you use each?

Use BackgroundService when you need a continuously running worker, such as:

• Processing messages from a queue
• Sending scheduled notifications
• Consuming events
• Periodically processing data
• Running background cleanup jobs

Use IHostedService when you need more direct control over the application startup and shutdown lifecycle, or when your background task doesn’t fit the ExecuteAsync() pattern.

Scenario-Based Interview Questions

Scenario-Based Interview Questions in ASP.NET Core interviews are designed to test how well you can apply your knowledge to real-world development and production problems, rather than simply recall definitions. Instead of asking “What is dependency injection?”, an interviewer may ask, “Your API is becoming slow as traffic increases. How would you identify and fix the performance bottleneck?” You may be given scenarios involving API performance, database optimization, caching, authentication and authorization, dependency injection, middleware, exception handling, concurrency, background services, logging, scalability, and security. These questions evaluate your ability to analyze a problem, identify its root cause, choose an appropriate ASP.NET Core feature or architecture, and explain why your solution is suitable.

96. Scenario 1 — Slow API – Your API takes 5 seconds to respond. CPU usage is low, but database usage is high. How would you investigate and fix it?

Your answer should include the areas:

SQL query analysis
EF Core generated SQL
indexes
AsNoTracking()
projection
pagination
N+1 queries
database profiling

97. Scenario 2 — High CPU – An API suddenly reaches 90% CPU because one user is sending thousands of requests. What would you do?

Expected answer:

rate limiting
authentication
per-user/IP partitioning
caching
monitoring
potentially blocking abusive clients

98. Scenario 3: Singleton Problem – A Singleton service depends on DbContext. Is this safe?

No. DbContext is normally scoped, and injecting a scoped service into a singleton creates a lifetime mismatch.

99. Scenario 4 : Authentication Works but Authorization Fails – A user has a valid JWT but receives 403 Forbidden. What would you investigate?

Check:

authentication succeeded
required role/claim
authorization policy
claim type
issuer
audience
middleware order

100. Scenario 5 : Duplicate Database Records – Two requests arrive simultaneously and create the same record. How would you prevent duplicates?

Possible solutions:

database unique constraint
transaction
concurrency handling
idempotency keys
appropriate application-level locking where necessary
Top 20 Questions to Prepare First

These ASP.NET Core interview questions cover the most important concepts, practical scenarios, and real-world problems that you are highly likely to encounter in an ASP.NET Core interview. Make sure you understand not just the answers, but also the reasoning behind them, because interviewers often ask follow-up and scenario-based questions to test your practical knowledge. Don’t just read these questions—practice answering them aloud, revisit the topics you find difficult, and make sure you can explain each concept confidently with real-world examples. If you can master these questions and understand the concepts behind them, you will be much better prepared to face your ASP.NET Core interview with confidence. Now it’s your turn: start revising, keep practicing, and walk into your interview fully prepared to succeed. My very best wishes for your ASP.NET Core interview—go confidently, give it your best, and I hope you qualify with flying colors!

The post ASP.NET Core Interview Questions and Answers – Crack Your Next Interview appeared first on YogiHosting.

With the Visual Studio 2022 HTTP File Editor, you can:

• Create and manage .http files for organizing and storing API requests.
• Send HTTP requests (GET, POST, PUT, DELETE, PATCH, and more) directly from Visual Studio.
• View and inspect HTTP responses, including status codes, headers, and response bodies, without leaving the editor.

This built-in feature streamlines Web API testing, improves developer productivity, and provides a seamless workflow for developing, debugging, and validating ASP.NET Core Web APIs within Visual Studio.

Create a .http file

Follow the steps to create a .http file in Visual Studio.

• In Solution Explorer, right-click the project name.
• In the context menu, select Add > New Item.
• In the Add New Item dialog, put http in the search box. This will show the http file.
• Select HTTP File, and select Add.

By default the .http is empty. We will add test codes in just a moment. But before that we need to see our Web API.

We have our Minimal API code which performs CRUD operations on a Work class.

The following code defines a set of ASP.NET Core Minimal API endpoints for performing CRUD (Create, Read, Update, and Delete) operations on a Work resource. The MapPost() endpoint creates a new work item and returns a 201 Created response with the resource location. The MapGet() endpoints retrieve all work items, fetch only completed items, or return a specific work item by its ID.

The MapPut() endpoint updates an existing work item after verifying that it exists. The MapPatch() endpoint updates an existing work by HTTP Patch method. In the last their is MapDelete() endpoint which removes a work item from the database. Each endpoint uses Entity Framework Core through the WorkDb context to interact with the database asynchronously, ensuring efficient and responsive API operations.

app.MapPost("/works", async (Work work, WorkDb db) =>
{
    db.Works.Add(work);
    await db.SaveChangesAsync();

    return Results.Created($"/works/{work.Id}", work);
});

app.MapGet("/works", async (WorkDb db) =>
    await db.Works.ToListAsync());

app.MapGet("/works/{id}", async (int id, WorkDb db) =>
    await db.Works.FindAsync(id)
        is Work work
            ? Results.Ok(work)
            : Results.NotFound());

app.MapPut("/works/{id}", async (int id, Work work, WorkDb db) =>
{
    var todo = await db.Works.FindAsync(id);

    if (todo is null) return Results.NotFound();

    todo.Name = work.Name;
    todo.TimeStart = work.TimeStart;
    todo.TimeEnd = work.TimeEnd;
    todo.IsComplete = work.IsComplete;

    await db.SaveChangesAsync();

    return Results.NoContent();
});

app.MapPatch("/works/{id}", async (int id, WorkDto workDto, WorkDb db) =>
{
    var todo = await db.Works.FindAsync(id);

    if (todo is null) return Results.NotFound();

    if (workDto.Name is not null) todo.Name = workDto.Name;
    if (workDto.IsComplete is not null) todo.IsComplete = workDto.IsComplete.Value;
    if (workDto.TimeStart is not null) todo.TimeStart = workDto.TimeStart;
    if (workDto.TimeEnd is not null) todo.TimeEnd = workDto.TimeEnd;

    await db.SaveChangesAsync();

    return Results.NoContent();
});

app.MapDelete("/works/{id}", async (int id, WorkDb db) =>
{
    if (await db.Works.FindAsync(id) is Work work)
    {
        db.Works.Remove(work);
        await db.SaveChangesAsync();
        return Results.NoContent();
    }

    return Results.NotFound();
});

The work class is given below:

public class Work
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string TimeStart { get; set; }
    public string TimeEnd { get; set; }
    public bool IsComplete { get; set; }
}

The WorkDto.cs is:

public class WorkDto
{
    public string Name { get; set; }

    public string TimeStart { get; set; }

    public string TimeEnd { get; set; }

    public bool? IsComplete { get; set; }
}

Now we are going to test this Web API with .http file.

Endpoints Explorer in Visual Studio

The Endpoints Explorer is a Visual Studio tool window that displays all the endpoints available in your ASP.NET Core Web API. It provides a convenient way to view your API routes and quickly test them by generating or using a .http file, allowing you to send HTTP requests directly from within Visual Studio.

Open Endpoints Explorer

Select View > Other Windows > Endpoints Explorer. This will open Endpoints Explorer.

The Endpoints Explorer will show all the Web API Endpoints defined in the app. If you don’t see the endpoints then click the Refresh button. See below image:

We can now generate request to the .http file. For this, in the Endpoints Explorer, right click on the GET Endpoint on /Work and select Generate Request.

The request is added to that .http file as shown below:

@WorkApi_HostAddress = https://localhost:7026

GET {{WorkApi_HostAddress}}/works

###

Here’s what each part does:

@WorkApi_HostAddress = https://localhost:7026

• This defines a variable named WorkApi_HostAddress.
• The @ prefix marks it as a variable declaration.
• Its value is https://localhost:7026 — likely the base URL of a locally running Web API project (the port 7026 is typical of an ASP.NET Core project running over HTTPS during development).

GET {{WorkApi_HostAddress}}/works

• This is the actual HTTP request.
• GET is the HTTP method.
• {{WorkApi_HostAddress}} inserts the value of the variable defined above using double-curly-brace syntax.
• So this line effectively resolves to:

GET https://localhost:7026/works

It sends a GET request to the /works endpoint — presumably a controller/route in the API that returns a list of “works” (e.g., work items, projects, or records, depending on the app’s domain).

http
###

• This is a request separator.
• .http files can contain multiple requests in one file, and ### marks the boundary between them, so tools know where one request ends and the next begins.
• Since there’s nothing after it here, it just marks the end of this single request block (and would let you add another request below it if needed).

If you click “Send Request” (you’d see a clickable link above the GET line) it will:

• Substitute the variable.
• Fire off an HTTPS GET request to https://localhost:7026/works.
• Show you the response (status code, headers, body) in the Response pane given on the side.

Note that you have to run the project before you make any API request. Also since there are no work records in the database so you will see an empty response. Lets start by posting data with .http file editor.

Test POST Endpoint with .http File Editor

The Minimal API Post Endpoint create a Work record and it’s code is given below:

app.MapPost("/works", async (Work work, WorkDb db) =>
{
    db.Works.Add(work);
    await db.SaveChangesAsync();

    return Results.Created($"/works/{work.Id}", work);
});

Lets test it.

In the Endpoints Explorer, right click on the POST Endpoint on /Work and select Generate Request.

POST request code lines will be added to the .http file as shown below:

POST {{WorkApi_HostAddress}}/works

###

A POST request requires both headers and a request body. To define these components, add the following lines immediately after the POST request line:

Content-Type: application/json

{
  "name":"eat breakfast",
  "isComplete":true,
  "timeStart":"8:00:00",
  "timeEnd":"8:30:00"
}

The preceding code adds a Content-Type header and a JSON request body. The file contents now look as:

@WorkApi_HostAddress = https://localhost:7026

POST {{WorkApi_HostAddress}}/works
Content-Type: application/json

{
  "name":"eat breakfast",
  "isComplete":true,
  "timeStart":"8:00:00",
  "timeEnd":"8:30:00"
}
###

Click the Send request link that is above the POST request line. The POST request is sent to the API and the response is displayed in the Response pane.

You will see 201 Created response along with the json of the newly created work record.

{
  "id": 1,
  "name": "eat breakfast",
  "timeStart": "8:00:00",
  "timeEnd": "8:30:00",
  "isComplete": true
}

Click on the Headers link to see the Request Headers.

Also click on the Raw link to see the full Request and Response made to the API.

Test GET Endpoints with .http File Editor

The Minimal API has 2 GET Endpoints as defined below. The first one gets all the Work records while the second get a particular Work record by it’s ID.

app.MapGet("/works", async (WorkDb db) =>
    await db.Works.ToListAsync());

app.MapGet("/works/{id}", async (int id, WorkDb db) =>
    await db.Works.FindAsync(id)
        is Work work
            ? Results.Ok(work)
            : Results.NotFound());

In Endpoints Explorer, right-click the first GET endpoint, and select Generate request. This is the same thing we did earlier for the POST endpoint to.

The following content is added to the .http file:

GET {{WorkApi_HostAddress}}/works

###

Now, select the Send request link that is given above the new GET request line.

The GET request is sent to the Minimal Web API and the response is displayed in the Response pane.

The response body is similar to the following JSON:

[
  {
    "id": 1,
    "name": "eat breakfast",
    "timeStart": "8:00:00",
    "timeEnd": "8:30:00",
    "isComplete": true
  }
]

Also check the below image where we have shown this:

Next, in Endpoints Explorer, right-click the /works/{id} GET endpoint and select Generate request. The following content is added to the .http file:

@id=0
GET {{WorkApi_HostAddress}}/works/{{id}}

It now becomes:

@id=1
GET {{WorkApi_HostAddress}}/works/{{id}}

• Replace @id=0 with @id=1 since this is the Id of the 1st Work record whose value we have to fetch.
• Select the Send request link that is above the new GET request line.
• The GET request is sent to the app and the response is displayed in the Response pane.

The response body is similar to the following JSON:

{
  "id": 1,
  "name": "eat breakfast",
  "timeStart": "8:00:00",
  "timeEnd": "8:30:00",
  "isComplete": true
}

We have shown this in the below image:

Test PUT Endpoint with .http File Editor

The Minimal Web API’s PUT Endpoint updates a given Work record and is given below:

app.MapPut("/works/{id}", async (int id, Work work, WorkDb db) =>
{
    var todo = await db.Works.FindAsync(id);

    if (todo is null) return Results.NotFound();

    todo.Name = work.Name;
    todo.TimeStart = work.TimeStart;
    todo.TimeEnd = work.TimeEnd;
    todo.IsComplete = work.IsComplete;

    await db.SaveChangesAsync();

    return Results.NoContent();
});

Before making a PUT request, make sure the item already exists in the database. If necessary, first send a POST request to create the item, and then use the PUT request to update it.

In Endpoints Explorer, right-click the PUT endpoint and select Generate request. Visual Studio adds the following content to the .http file:

PUT {{WorkApi_HostAddress}}/works/{{id}}
Content-Type: application/json

{
  //Work
}

###

We need to update it so in the PUT request line, replace {id} with 1. This is the Id of the Work records that needs to be updated. Then add the following lines containing the json of the Work record in side the curly brackets:

"id": 1,
"name":"eat supper",
"timeStart":"9:00:00",
"timeEnd":"9:30:00",
"isComplete":false

It now becomes:

PUT {{WorkApi_HostAddress}}/works/1
Content-Type: application/json

{
  "id": 1,
  "name":"eat supper",
  "timeStart":"9:00:00",
  "timeEnd":"9:30:00",
  "isComplete":false
}

###

We added a Content-Type header and a JSON request body of the Work that is to be updated. Notice I have changed the values of name to “eat supper”, IsComplete to “false” and also the times.

Now, select the Send request link above the new PUT request to send the request.

The PUT request is sent to the application, and the response appears in the Response pane. Because the operation completes successfully without returning content, the response body is empty and the HTTP status code is 204 No Content.

Check the record is updated by making a GET request to the API again.

Suppose If we try to update a records which is not present in the database then we will get 404 Not Found response. Change the id value to 50, the code now becomes:

PUT {{WorkApi_HostAddress}}/works/50
Content-Type: application/json

{
  "id": 1,
  "name":"eat supper",
  "timeStart":"9:00:00",
  "timeEnd":"9:30:00",
  "isComplete":false
}

###

Since 50 th Work records is not present so we will get 404 Not Found response, check below image:

Test PATCH Endpoints with .http File Editor

The Minimal Web API’s PATCH Endpoint updates a given Work record by HTTP PATCH method:

app.MapPatch("/works/{id}", async (int id, WorkDto workDto, WorkDb db) =>
{
    var todo = await db.Works.FindAsync(id);

    if (todo is null) return Results.NotFound();

    if (workDto.Name is not null) todo.Name = workDto.Name;
    if (workDto.IsComplete is not null) todo.IsComplete = workDto.IsComplete.Value;
    if (workDto.TimeStart is not null) todo.TimeStart = workDto.TimeStart;
    if (workDto.TimeEnd is not null) todo.TimeEnd = workDto.TimeEnd;

    await db.SaveChangesAsync();

    return Results.NoContent();
});

Lets test it. On the Endpoints Explorer, right-click the PATCH endpoint, and select Generate request. This adds the following code to the http file:

PATCH {{WorkApi_HostAddress}}/works/{id}

###

In the PATCH request line, replace {id} with 1 since we will update the 1st records. Next, add the following code lines after it.

Content-Type: application/json

{
  "name": "sleep",
  "isComplete":false
}

The above code adds a Content-Type header and a JSON request body with only 2 fields to update. These are:

• name
• isComplete

The full Patch code becomes.

PATCH {{WorkApi_HostAddress}}/works/{id}
Content-Type: application/json

{
  "name": "sleep",
  "isComplete":false
}

###

Select the Send request link that is above the new PATCH request line.

The PATCH request is sent to the application, and the response appears in the Response pane. The response body is empty, and the HTTP status code is 204 No Content, indicating that the update was completed successfully without returning any content.

Make a new GET request to the API to confirm the change has been made to the Work.

Test DELETE Endpoints with .http File Editor

The Minimal API Delete endpoint is:

app.MapDelete("/works/{id}", async (int id, WorkDb db) =>
{
    if (await db.Works.FindAsync(id) is Work work)
    {
        db.Works.Remove(work);
        await db.SaveChangesAsync();
        return Results.NoContent();
    }

    return Results.NotFound();
});

Lets test this endpoint. Just like what we did before, start by right-clicking the DELETE endpoint in the Endpoints Explorer, and select Generate request.

A DELETE request is added to http file.

Replace {id} in the DELETE request line with 1. It will now look as:

DELETE {{WorkApi_HostAddress}}/works/1

###

Select the Send request link for the DELETE request. Visual Studio sends the request to the application, and the response appears in the Response pane. The response body is empty, and the HTTP status code is 204 No Content, indicating that the resource was successfully deleted.

Make a GET request to confirm the Work is indeed deleted.

Test File Upload Endpoints with .http File Editor

The Minimal API has an endpoint to upload files. Check the below code:

app.MapPost("/upload", async (IFormFile file) =>
{
    if (file == null || file.Length == 0)
        return Results.BadRequest("No file uploaded.");

    var filePath = Path.Combine("Uploads", file.FileName);

    Directory.CreateDirectory(Path.GetDirectoryName(filePath)!);

    using var stream = new FileStream(filePath, FileMode.Create);
    await file.CopyToAsync(stream);

    return Results.Ok(new
    {
        file.FileName,
        file.Length
    });
}).DisableAntiforgery();

The API code above accepts the uploaded file as an IFormFile parameter and saves it to the Uploads directory.

Notice that we have disabled anti-forgery token by adding DisableAntiforgery(). This is only done for testing it using a .http file. Otherwise we will get the following error:

Invalid anti-forgery token found when reading parameter "IFormFile file"

Right-clicking the POST /upload endpoint in the Endpoints Explorer, and select Generate request.

Update the code as shown below:

POST {{WorkApi_HostAddress}}/upload
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="sample.txt"
Content-Type: text/plain

< ./sample.txt
------WebKitFormBoundary7MA4YWxkTrZu0gW--

The above code uploads sample.txt file to the /upload endpoint as a multipart/form-data request.

Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

multipart/form-data tells the server that the request contains form data that may include files.

The boundary separates the individual parts of the request. In this example, the boundary is:

----WebKitFormBoundary7MA4YWxkTrZu0gW

The same boundary must be used throughout the request.

------WebKitFormBoundary7MA4YWxkTrZu0gW

This marks the beginning of a part in the multipart request.

In this case, there is one part: the uploaded file.

Content-Disposition: form-data; name="file"; filename="sample.txt"

This line provides information about the form field and the file.

• form-data — indicates that this is a form-data field.
• name=”file” — must match the parameter name in your Minimal API.

IFormFile file

filename=”sample.txt” — specifies the name of the uploaded file.

The name=”file” part is particularly important because ASP.NET Core uses it to bind the uploaded file to.

Content-Type: text/plain

This tells the server that sample.txt contains plain-text data.

For example, if you were uploading a PDF, you could use:

Content-Type: application/pdf

Read the file:

< ./sample.txt	

This is an important feature of the Visual Studio .http file editor.

The “<” operator tells Visual Studio to read the contents of sample.txt from the local filesystem and use them as the body of this multipart section.

End of the multipart request:

------WebKitFormBoundary7MA4YWxkTrZu0gW--

The final — after the boundary indicates that this is the end of the multipart request.

Before you click the Send request make an “Uploads” directory in the app root folder. Finally, select the Send request link to upload the file.

The below image shows the response.

Open the “Uploads” folder to find the “sample.txt” file uploaded successfully. The file content will be < ./sample.txt. See below image:

Understanding .http file in Details

We will now go through details of .http file so that you can understand how to write request based on different conditions.

Request headers

To add one or more headers, place each header on its own line directly after the request line, with no blank lines separating the request line from the first header or between the headers themselves. Each header follows the format HeaderName: Value, as shown in the example below:

GET https://localhost:8778/weatherforecast
Cache-Control: max-age=857800
Age: 150

###

Here we have 2 headers: Cache-Control with value max-age=857800. And Age with value 150.

Request body

To include a body with a request (typically for POST, PUT, or PATCH), leave exactly one blank line after the last header, then write the body content starting on the next line — this blank line is required to separate headers from the body. For a JSON body, set Content-Type: application/json as a header and write the JSON directly below:

# creating a new work by making a post request to the API
POST https://localhost:8778/api/work
Content-Type: application/json

{
  "title": "Buy groceries",
  "isComplete": false
}

Note that lines that start with either # or // are comments.

Variables

In a Visual Studio .http file, you define a variable on a line that starts with @, using the syntax @VariableName=Value. Variable names are case-sensitive and can’t contain spaces. The value can be any characters, including null to represent a null value.

Once defined, a variable can be referenced in any request that appears later in the file. To reference it, wrap the variable name in double curly braces: {{ and }}. The example below shows two variables being defined and then used in a request:

@hostname=localhost
@port=99887
GET https://{{hostname}}:{{port}}/works

Variables can also be defined in terms of other variables, as long as those variables were defined earlier in the file. The example below uses a single combined variable in the request, instead of the two separate variables shown in the previous example:

@hostname=localhost
@port=99887
@host={{hostname}}:{{port}}
GET https://{{host}}/works

Environment files

To assign different values to variables for different environments, create a file named http-client.env.json. Place this file in the same directory as your .http file or in any of its parent directories. Visual Studio uses this environment file to provide environment-specific variable values when sending HTTP requests.

The following example demonstrates the structure of an http-client.env.json environment file:

{
  "dev": {
    "HostAddress": "https://localhost:99887"
  },
  "remote": {
    "HostAddress": "https://yogihosting.com"
  }
}

An environment file is a JSON file that defines one or more named environments, such as dev and remote. Each environment contains one or more variables, such as HostAddress, with values specific to that environment.

Variables defined in an environment file are referenced in the same way as regular .http file variables, using double curly braces such as {{HostAddress}}. The following example demonstrates how to reference an environment variable in an HTTP request:

GET {{HostAddress}}/works

The value assigned to a variable when an HTTP request is sent depends on the environment selected from the environment selector dropdown in the upper-right corner of the .http file editor. Select the required environment to use its corresponding variable values when executing the request. The following screenshot shows the environment selector:

The environment file does not need to be located in the project folder. Visual Studio searches for a file named http-client.env.json starting in the directory that contains the .http file. If the file is not found there, Visual Studio continues searching each parent directory until it finds one. The search stops as soon as a matching file is found, so the closest http-client.env.json file to the .http file takes precedence.

Visual Studio displays warnings in the following situations:

• The .http file references a variable that is not defined in either the .http file or the environment file.
• The environment file defines a variable that is not referenced anywhere in the .http file.

A variable can be defined in both the .http file and the environment file. When the same variable exists in both files, the value defined directly in the .http file takes precedence over the value defined in the environment file.

Shared variables

$shared is a special environment name used to define variables whose values are common across multiple environments. Instead of repeating the same variable in each environment, you can define it once under $shared and reuse it across environments.

For example, consider the following http-client.env.json environment file:

{
    "$shared": {
        "HostAddress": "https://localhost:99887"
    },
    "dev1": {
        "username": "Jack"
    },
    "dev2": {
        "username": "Alice"
    },
    "staging": {
        "username": "staginguser",
        "HostAddress": "https://staging.yogihosting.com"
    }
}

In the preceding example, the $shared environment defines the HostAddress variable with the value localhost:99887. This value serves as a default for any environment that does not define its own HostAddress variable.

Therefore, when the “dev1” or “dev2” environment is selected, HostAddress uses the value from $shared because neither environment defines its own value. However, the staging environment defines HostAddress as https://staging.yogihosting.com, so that value takes precedence over the $shared default.

Request variables

In a Visual Studio .http file, request variables are variables that are created from the response of one HTTP request and then used in subsequent requests. They are useful when one request depends on data returned by another request—for example, using an authentication token or an ID returned from a POST request.

Request variables enable you to automate this process. For example, suppose an .http file contains a request that authenticates the user and is named login. The response from this request is a JSON object containing a bearer token in a property named token. You can then use this token in subsequent requests by passing it in the Authorization header. The following example demonstrates how to accomplish this:

@WorkApi_HostAddress = https://localhost:7026

# @name login

POST {{WorkApi_HostAddress}}/login 
Content-Type: application/json 

{ 
  "name":"eat breakfast", 
  "isComplete":true, 
  "timeStart":"8:00:00", 
  "timeEnd":"8:30:00" 
}

### 

GET {{WorkApi_HostAddress}}/works 
Authorization: Bearer {{login.response.body.$.token}} 

###

The expression {{login.response.body.$.token}} is used to retrieve the bearer token from the response of the login request. Each part of the expression has a specific purpose:

• login: The name assigned to the HTTP request.
• response: Refers to the response returned by that request.
• body: Refers to the response body.
• $: Represents the root of the JSON document in the response body.
• token: Identifies the token property whose value is extracted from the JSON response.

User-specific environment files

A user-specific value is a value that a developer needs for testing but does not want to share with other team members. Since the http-client.env.json file is typically checked into source control, you should not store user-specific values in this file. Instead, Visual Studio provides a separate file named http-client.env.json.user for storing personal or local environment values. This file is located in the same folder as the http-client.env.json file. Files with the .user extension are excluded from source control by default when using Visual Studio’s built-in source control features.

When Visual Studio loads an http-client.env.json file, it automatically looks for a corresponding http-client.env.json.user file in the same directory. If the same variable is defined in both files for the same environment, the value from the http-client.env.json.user file takes precedence.

The following example demonstrates how a user-specific environment file works. Suppose the .http file contains the following content:

GET {{WorkApi_HostAddress}}/{{Path}}
Accept: application/json

Let the http-client.env.json file contains the following content:

{
  "dev": {
    "WorkApi_HostAddress": "https://localhost:99887",
    "Path": "works"
  },
  "remote": {
    "WorkApi_HostAddress": "https://yogihosting.com",
    "Path": "works"
  }
}

If there’s a user-specific environment file that contains the following content:

{
  "dev": {
    "Path": "swagger/index.html"
  }
}

When the user selects the “dev” environment, the request is sent to https://localhost:99887/swagger/index.html because the Path value in the http-client.env.json.user file overrides the value from the http-client.env.json file.

With the same environment files, suppose the variables are defined in the .http file:

@WorkApi_HostAddress=https://yogihosting.com
@Path=works

GET {{WorkApi_HostAddress}}/{{Path}}
Accept: application/json

In this scenario, the “dev” environment request is sent to https://yogihosting.com/works because variable definitions in .http files override environment file definitions.

ASP.NET Core User Secrets

When testing ASP.NET Core Web APIs using .http files in Visual Studio, you may need to work with sensitive values such as API keys, passwords, connection strings, or authentication tokens. These values should not be stored directly in the .http file or committed to source control.

ASP.NET Core provides User Secrets as a secure way to store sensitive development-time configuration values outside your project files.

For example, suppose your ASP.NET Core application has a secret named “ApiKey”. You can store it using the ASP.NET Core Secret Manager:

dotnet user-secrets set "ApiKey" "my-secret-api-key"

The secret is stored outside the project directory and is not committed to source control.

Visual Studio can access ASP.NET Core User Secrets through environment variables defined in the http-client.env.json file. For example:

{
  "dev": {
    "ApiKey": {
      "provider": "AspnetUserSecrets",
      "secretName": "ApiKey"
    }
  }
}

Here:

• ApiKey — the variable name you will use in the .http file.
• “provider”: “AspnetUserSecrets” — tells Visual Studio to get the value from ASP.NET Core User Secrets.
• “secretName”: “ApiKey” — specifies the name of the User Secret to retrieve.

You can then use the variable in your .http file request:

GET https://localhost:5001/api/products
X-API-Key: {{ApiKey}}

Here, {{ApiKey}} is replaced with the value defined for the ApiKey variable when the request is executed.

When you send the request, Visual Studio retrieves the value of the ApiKey User Secret and uses it in the X-API-KEY header. The actual secret value isn’t displayed by the .http editor’s autocomplete.

So the flow is:

dotnet user-secrets set "ApiKey" "my-secret-api-key"
                    │
                    ▼
             ASP.NET Core
             User Secrets
                    │
                    ▼
        http-client.env.json
        provider: AspnetUserSecrets
                    │
                    ▼
             {{ApiKey}}
                    │
                    ▼
       X-API-KEY: <secret value>

One important detail – The http-client.env.json file itself doesn’t contain the secret value, so it can safely be committed to source control:

{
  "dev": {
    "ApiKey": {
      "provider": "AspnetUserSecrets",
      "secretName": "ApiKey"
    }
  }
}

The actual value remains in ASP.NET Core’s User Secrets store, outside the project. ASP.NET Core’s Secret Manager is specifically intended for keeping development secrets out of source-controlled project files.

Azure Key Vault

This below http-client.env.json configuration tells Visual Studio’s .http file editor to retrieve a secret from Azure Key Vault and make it available as an HTTP client variable.

{
  "dev": {
    "AKVSecret": {
      "provider": "AzureKeyVault",
      "secretName": "SecretInKeyVault",
      "resourceId": "/subscriptions/3a914c59-8175-9e0e540/resourceGroups/my-key-vault-rg/providers/Microsoft.KeyVault/vaults/my-key-vault-01182024"
    }
  }
}

Note: To retrieve a value from Azure Key Vault, you must be signed in to Visual Studio with an account that has the necessary permissions to access the target Key Vault.

The variable is named AKVSecret which pulls its value from Azure Key Vault. Values of resourceId and secretName will be get from Azure portal.

The AKVSecret object defines the following properties:

Now the following .http file has a request that uses this secret value.

GET {{HostAddress}}{{Path}}
X-AKV-SECRET: {{akvSecret}}

Environment variables

$processEnv is a dynamic variable function in Visual Studio’s .http file editor that tells the HTTP client to read a value from the environment variables of the process running the request.

Example:

GET {{HostAddress}}{{Path}}
X-UserName: {{$processEnv USERNAME}}

{{$processEnv USERNAME}} – Get the value of the USERNAME environment variable. For example, if the process environment contains:

USERNAME=YogiHosting

then:

X-UserName: {{$processEnv USERNAME}}

effectively becomes:

X-UserName: Yogesh

.env files

To retrieve the value of a variable defined in a .env file, use the $dotenv dynamic variable. The .env file must be located in the project folder. The syntax for $dotenv is similar to $processEnv. For example, if the .env file contains the following:

API_KEY=my-secret-api-key
API_URL=https://api.example.com

You can access these values in a .http file using the $dotenv dynamic variable:

GET {{$dotenv API_URL}}/products
X-API-Key: {{$dotenv API_KEY}}

When the request is executed, Visual Studio reads the values from the .env file. The request is effectively sent as:

GET https://api.example.com/products
X-API-Key: my-secret-api-key

Random integers

To generate a random integer, use the $randomInt dynamic variable. Its syntax is {{$randomInt [min max]}}, where min and max are optional parameters that specify the minimum and maximum values for the generated integer.

Here are a few examples of using $randomInt in a Visual Studio .http file.

GET https://localhost:5001/api/products/{{$randomInt}}

Visual Studio generates a random integer and replaces {{$randomInt}} with the generated value.

GET https://localhost:5001/api/products/42

Generate a random integer within a range:

GET https://localhost:5001/api/products/{{$randomInt 1 100}}

This generates a random integer between 1 and 100.

GET https://localhost:5001/api/products/73

• $datetime generates a datetime string in UTC.
• $localDatetime generates a datetime string in the local time zone.
• $timestamp generates a timestamp in UTC.

Example:

GET https://localhost:5001/api/orders?createdAt={{$datetime}}

It might produce:

GET https://localhost:5001/api/orders?createdAt=2026-08-15T13:20:30Z

The link to download the full source code of this tutorial is given below:

Download

Overall, .http files are an effective tool for API development, debugging, automated test scenarios, and sharing reproducible HTTP requests with your development team. By using environment files and secure secret providers appropriately, you can keep your API testing workflow both flexible and secure.

The post Effortless ASP.NET Core Minimal API Testing with the Visual Studio HTTP Editor appeared first on YogiHosting.

A JSON Patch document is itself a JSON array of operations. Each operation specifies:

• op: the operation to perform
• path: a JSON Pointer identifying the target location
• Additional fields such as value or from, depending on the operation

Original document:

{
  "name": "Alice",
  "age": 30,
  "tags": ["admin"]
}

Patch:

[
  {
    "op": "replace",
    "path": "/age",
    "value": 31
  },
  {
    "op": "add",
    "path": "/tags/1",
    "value": "editor"
  }
]

Result:

{
  "name": "Alice",
  "age": 31,
  "tags": ["admin", "editor"]
}

/tags/1 -> Index 1 is the position immediately after the first element “admin”, so “editor” is inserted there. So it becomes “admin”, “editor”.

Supported operations:

Add a property:

{
  "op": "add",
  "path": "/email",
  "value": "alice@example.com"
}

Remove a property:

{
  "op": "remove",
  "path": "/email"
}

Move a value:

{
  "op": "move",
  "from": "/oldName",
  "path": "/newName"
}

Test before replacing:

[
  {
    "op": "test",
    "path": "/version",
    "value": 5
  },
  {
    "op": "replace",
    "path": "/version",
    "value": 6
  }
]

If the test operation fails, the entire patch fails.

JSON Patch is useful when:

• Updating REST API resources via HTTP PATCH
• Synchronizing documents between clients and servers
• Tracking edits efficiently
• Applying incremental changes in collaborative applications

It is especially valuable when only a small portion of a large JSON document changes, because it avoids sending the entire document.

JSON Patch vs HTTP Patch

JSON Patch and HTTP PATCH are related, but they are not the same thing.

• HTTP PATCH is an HTTP method (like GET, POST, PUT, DELETE).
• JSON Patch is a document format (RFC 6902) that is commonly used as the payload of an HTTP PATCH request.

Relationship:

HTTP PATCH (method)
        │
        ├── JSON Patch (RFC 6902)
        ├── JSON Merge Patch (RFC 7396)
        └── Custom partial update format

Note that a HTTP PATCH request can use different formats for its request body. JSON Patch is just one of them.

HTTP PATCH tells the server: “Update only part of this resource.”

PATCH /users/1 HTTP/1.1
Content-Type: application/json

{
  "age": 31
}

The HTTP specification does not define what the body should look like. That depends on the API.

JSON Patch defines how to describe changes.

PATCH /users/1 HTTP/1.1
Content-Type: application/json-patch+json

[
  {
    "op": "replace",
    "path": "/age",
    "value": 31
  }
]

JSON PATCH in ASP.NET Core Minimal API

In ASP.NET Core Minimal APIs, you can support JSON Patch (application/json-patch+json) using the Microsoft.AspNetCore.JsonPatch package. JSON Patch follows RFC 6902 and allows partial updates with operations like add, remove, replace, move, copy, and test.

1. Install the package

dotnet add package Microsoft.AspNetCore.JsonPatch.SystemTextJson

2. Create Models

Here we have Department and Employee class where Departments contains one or many Employees.

public class Department
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Manager { get; set; }
    public List<Employee>? Employees { get; set; }
}

public class Employee
{
    public int Id { get; set; }

    public string Name { get; set; }
    public DateTime JoiningDate { get; set; }
    public decimal Salary { get; set; }
}

3. JSON Patch code

This endpoint implements a JSON Patch endpoint in an ASP.NET Core Minimal API. It retrieves a Department from the database, applies the JSON Patch operations, reports any patch errors as validation errors, saves the changes, and returns the updated entity.

app.MapPatch("/customers/{id}", async Task<Results<Ok<Department>, ValidationProblem, NotFound<ProblemDetails>>> (WorkDb db, int id,
    JsonPatchDocument<Department> patchDoc) =>
{
    var department = await db.Departments.Include(c => c.Employees).FirstOrDefaultAsync(c => c.Id == id);
    
    if (department is null)
        return TypedResults.NotFound<ProblemDetails>(new());
    
    if (patchDoc != null)
    {
        Dictionary<string, string[]>? errors = null;
        patchDoc.ApplyTo(department, jsonPatchError =>
        {
            errors ??= new();
            var key = jsonPatchError.AffectedObject.GetType().Name;
            if (!errors.ContainsKey(key))
            {
                errors.Add(key, new string[] { });
            }
            errors[key] = errors[key].Append(jsonPatchError.ErrorMessage).ToArray();
        });

        if (errors != null)
        {
            return TypedResults.ValidationProblem(errors);
        }

        // Only save if there are no errors
        await db.SaveChangesAsync();
    }

    return TypedResults.Ok(department);
})
.Accepts<JsonPatchDocument<Department>>("application/json-patch+json");

Retrieve the Department:

The endpoint retrieves a Department object from the database from the provided id. When no department is found then it returns 404 Not Found response via TypedResults.NotFound() method.

Apply JSON Patch:

The ApplyTo(Object) method executes the JSON Patch operations defined in patchDoc on the retrieved Department object. If any errors occur while applying the patch, such as invalid paths, unsupported operations, or conflicting changes, the provided error-handling delegate is invoked. The delegate captures these errors and stores the corresponding error messages in a dictionary, using the affected object’s type name as the key.

Return validation errors:

If the error-handling delegate detects any issues while applying the patch operations, the endpoint returns a ValidationProblem response using TypedResults.ValidationProblem(errors), which includes the collected error details.

Save and return the Updated Department:

If the patch operations are applied successfully without any errors, the changes are persisted to the database using SaveChangesAsync(). The endpoint then returns the updated Customer object in an OK response through TypedResults.Ok(department).

Example error response

The following example demonstrates the response body of a validation problem returned for a JSON Patch operation when the specified path is invalid:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
    "Department": [
      "The target location specified by path segment 'Admin' was not found."
    ]
  }
}

Testing with .http File Editor in Visual Studio

We have 2 Departments and each department containing 2 Employees. See below structure:

[
  {
    "id": 1,
    "name": "Development",
    "manager": "Adam Dorsey",
    "employees": [
      {
        "id": 1,
        "name": "John Doe",
        "joiningDate": "2024-08-04T20:18:50.1041658+05:30",
        "salary": 60000
      },
      {
        "id": 2,
        "name": "Jane Smith",
        "joiningDate": "2025-08-04T20:18:50.1042795+05:30",
        "salary": 55000
      }
    ]
  },
  {
    "id": 2,
    "name": "Support",
    "manager": "Elon Musk",
    "employees": [
      {
        "id": 3,
        "name": "Alice Johnson",
        "joiningDate": "2023-08-04T20:18:50.1042808+05:30",
        "salary": 70000
      },
      {
        "id": 4,
        "name": "Bob Brown",
        "joiningDate": "2022-08-04T20:18:50.104281+05:30",
        "salary": 65000
      }
    ]
  }
]

To replace the 1st Manager name from John Doe to Jack Doe, the Patch request is:

PATCH {{DailyWork_HostAddress}}/departments/1
Content-Type: application/json-patch+json

[
  {
    "op": "replace",
    "path": "/Manager",
    "value": "Jack Doe"
  }
]

We used replace for “op” and given path as “/Manager” with value containing the new name i.e. Jack Doe.

Lets send a Patch request to add a new Employee in the 1st department. The patch request is given below.

PATCH {{DailyWork_HostAddress}}/departments/1
Content-Type: application/json-patch+json

[
  {
    "op": "add",
    "path": "/Employees/-",
    "value": {
      "name": "Yogi S",
      "joiningDate": "2026-08-04T00:00:00",
      "salary": 165000
    }
  }
]

Why /Employees/-? In JSON Patch:

• /Employees/0 → insert at index 0
• /Employees/1 → insert at index 1
• /Employees/- → append to the end of the array

The “-” is defined by the JSON Patch specification to mean “append”.

To insert at index 0:

PATCH {{DailyWork_HostAddress}}/departments/1
Content-Type: application/json-patch+json

[
  {
    "op": "add",
    "path": "/Employees/0",
    "value": {
      "name": "Alice Johnson",
      "joiningDate": "2026-08-04T00:00:00",
      "salary": 65000
    }
  }
]

Update an existing employee – For example, change the first employee’s salary:

PATCH {{DailyWork_HostAddress}}/departments/1
Content-Type: application/json-patch+json

[
  {
    "op": "replace",
    "path": "/Employees/0/Salary",
    "value": 70000
  }
]

Remove the second employee:

PATCH {{DailyWork_HostAddress}}/departments/1
Content-Type: application/json-patch+json

[
  {
    "op": "remove",
    "path": "/Employees/1"
  }
]

More complicated scenarios include replacing Manger name and at the same time adding a new Employee. Check the below request which does this thing in one request only.

PATCH {{DailyWork_HostAddress}}/departments/1
Content-Type: application/json-patch+json

[
  {
    "op": "replace",
    "path": "/Manager",
    "value": "Jack Doe"
  },
  {
    "op": "add",
    "path": "/Employees/-",
    "value": {
      "name": "Yogi S",
      "joiningDate": "2026-08-04T00:00:00",
      "salary": 165000
    }
  }
]

Test in JSON Patch

JSON Patch supports the test operation, which verifies that the value of a specified property matches an expected value. If the values do not match, the operation fails and the server returns an error without applying the patch.

In the below patch request we test if the Department name is “Developement” only then replace manager to “Yogi S.”.

PATCH {{DailyWork_HostAddress}}/departments/1
Content-Type: application/json-patch+json

[
  {
    "op": "test",
    "path": "/Name",
    "value": "Development"
  },
  {
    "op": "replace",
    "path": "/Manager",
    "value": "Yogi S"
  }
]

Suppose we send the Name as “Testing”. See below request.

PATCH {{DailyWork_HostAddress}}/departments/1
Content-Type: application/json-patch+json

[
  {
    "op": "test",
    "path": "/Name",
    "value": "Testing"
  },
  {
    "op": "replace",
    "path": "/Manager",
    "value": "Yogi S"
  }
]

Since here the department name does not match so we get an error response.

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
    "Department": [
      "The current value 'Development' at path 'Name' is not equal to the test value 'Testing'."
    ]
  }
}

Certainly this is a helpful feature to prevent unwanted changes.

In this tutorial we learned how to use JSON PATCH in ASP.NET Core Minimal API. We also checked all the examples to understand it’s uses. If you find it useful then please share it on your social media account with your friends.

The post How to use JSON Patch in ASP.NET Core Minimal API appeared first on YogiHosting.

In this tutorial we will be performing both Unit and Integration Testing in Minimal APIs.

ASP.NET Core Minimal API Project

On our last tutorial we created our ASP.NET Core Minimal API from Start till Finish. The Program.cs class creates a route group in an ASP.NET Core Minimal API and registers all endpoints related to the Works resource under the /works base URL.

• app.MapGroup(“/works”) creates a route group with the common prefix /works.
• WorkAPIV1() & WorkAPIV2() are 2 custom extension method that maps all the endpoints (such as GET, POST, PUT, and DELETE) to that route group.
• We have 2 sets of Minimal API for these 2 custom extension methods. The first starts with /works/v1 while second starts with /works/v2.
• We also registered an In-Memory database and an interface called IWorkService.

See the code below.

using DailyWork;
using Microsoft.AspNetCore.Http.HttpResults;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Options;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddTransient<IWorkService, WorkService>();

builder.Services.AddDbContext<WorkDb>(opt => opt.UseInMemoryDatabase("WorkDatabase"));

var app = builder.Build();

app.MapGet("/", () => "Welcome to Minimal API Project");

app.MapGroup("/works/v1").WorkAPIV1();
app.MapGroup("/works/v2").WorkAPIV2();

app.Run();

The Work.cs class is:

public class Work
{
	public int Id { get; set; }
	public string Name { get; set; }

	public string TimeStart { get; set; }

	public string TimeEnd { get; set; }

	public bool IsComplete { get; set; }

    public string? Secret { get; set; }
}

Next, there is a static class called WorkEndpointV1 that contains the custom extension method called WorkAPIV1().

public static class WorkEndpointV1
{
    public static RouteGroupBuilder WorkAPIV1(this RouteGroupBuilder workGroup)
    {
        workGroup.MapPost("/", CreateWork)
                 .AddEndpointFilter(async (invocationContext, next) =>
                 {
                     var w = invocationContext.GetArgument<Work>(0);

                     var validationErrors = Utilities.IsValid(w);

                     if (validationErrors.Any())
                     {
                         return Results.ValidationProblem(validationErrors);
                     }

                     return await next(invocationContext);
                 });
        workGroup.MapGet("/", GetAllWork);
        workGroup.MapGet("/complete", GetCompletedWork);
        workGroup.MapGet("/{id}", GetWorkById);
        workGroup.MapPut("/{id}", UpdateWorkById);
        workGroup.MapPatch("/{id}", UpdateWorkByIdWithPatch);
        workGroup.MapDelete("/{id}", DeleteWorkById);

        return workGroup;
    }

    public static async Task<Created<Work>> CreateWork(Work work, WorkDb db)
    {
        db.Works.Add(work);
        await db.SaveChangesAsync();

        return TypedResults.Created($"/works/{work.Id}", work);
    }

    public static async Task<Ok<Work[]>> GetAllWork(WorkDb db)
    {
        return TypedResults.Ok(await db.Works.ToArrayAsync());
    }

    public static async Task<Ok<Work[]>> GetCompletedWork(WorkDb db)
    {
        return TypedResults.Ok(await db.Works.Where(t => t.IsComplete).ToArrayAsync());
    }

    public static async Task<Results<Ok<Work>, NotFound>> GetWorkById(int id, WorkDb db)
    {
        return await db.Works.FindAsync(id)
            is Work work
                ? TypedResults.Ok(work)
                : TypedResults.NotFound();
    }

    public static async Task<Results<NoContent, NotFound>> UpdateWorkById(int id, Work work, WorkDb db)
    {
        var w = await db.Works.FindAsync(id);

        if (w is null) return TypedResults.NotFound();

        w.Name = work.Name;
        w.TimeStart = work.TimeStart;
        w.TimeEnd = work.TimeEnd;
        w.IsComplete = work.IsComplete;

        await db.SaveChangesAsync();

        return TypedResults.NoContent();
    }
    public static async Task<IResult> UpdateWorkByIdWithPatch(int id, WorkDto workDto, WorkDb db)
    {
        var w = await db.Works.FindAsync(id);

        if (w is null) return TypedResults.NotFound();

        if (workDto.Name is not null) w.Name = workDto.Name;
        if (workDto.IsComplete is not null) w.IsComplete = workDto.IsComplete.Value;
        if (workDto.TimeStart is not null) w.TimeStart = workDto.TimeStart;
        if (workDto.TimeEnd is not null) w.TimeEnd = workDto.TimeEnd;

        await db.SaveChangesAsync();

        return TypedResults.NoContent();
    }

    public static async Task<Results<NoContent, NotFound>> DeleteWorkById(int id, WorkDb db)
    {
        if (await db.Works.FindAsync(id) is Work work)
        {
            db.Works.Remove(work);
            await db.SaveChangesAsync();
            return TypedResults.NoContent();
        }

        return TypedResults.NotFound();
    }
}

The above code simply performs the CRUD operations when the api GET, POST, PUT, and DELETE endpoints are called.

We also define a Utilities.cs class which is called by the filter for validating the Work class Name field. This makes sure that the Name field is not empty and should have more than 2 characters in length.

public static class Utilities
{
    public static Dictionary<string, string[]> IsValid(Work w)
    {
        Dictionary<string, string[]> errors = new();

        if (string.IsNullOrEmpty(w.Name))
        {
            errors.TryAdd("work.name.errors", new[] { "Name is empty" });
        }

        if (w.Name.Length < 3)
        {
            errors.TryAdd("work.name.errors", new[] { "Name length < 3" });
        }

        return errors;
    }
}

Moving to static class called WorkEndpointV2 that contains the custom extension method called WorkAPIV2(). See it’s code below:

public static class WorkEndpointV2
{
    public static RouteGroupBuilder WorkAPIV2(this RouteGroupBuilder workGroup)
    {
        workGroup.MapPost("/", CreateWork)
                 .AddEndpointFilter(async (invocationContext, next) =>
                 {
                     var w = invocationContext.GetArgument<Work>(0);

                     var validationErrors = Utilities.IsValid(w);

                     if (validationErrors.Any())
                     {
                         return Results.ValidationProblem(validationErrors);
                     }

                     return await next(invocationContext);
                 });
        workGroup.MapGet("/", GetAllWork);
        workGroup.MapGet("/complete", GetCompletedWork);
        workGroup.MapGet("/{id}", GetWorkById);
        workGroup.MapPut("/{id}", UpdateWorkById);
        workGroup.MapPatch("/{id}", UpdateWorkByIdWithPatch);
        workGroup.MapDelete("/{id}", DeleteWorkById);

        return workGroup;
    }
    public static async Task<Created<Work>> CreateWork(Work work, IWorkService workService)
    {
        await workService.Add(work);

        return TypedResults.Created($"/works/{work.Id}", work);
    }

    public static async Task<Ok<List<Work>>> GetAllWork(IWorkService workService)
    {
        return TypedResults.Ok(await workService.GetAll());
    }

    public static async Task<Ok<List<Work>>> GetCompletedWork(IWorkService workService)
    {
        return TypedResults.Ok(await workService.GetCompleteWork());
    }

    public static async Task<Results<Ok<Work>, NotFound>> GetWorkById(int id, IWorkService workService)
    {
        return await workService.Find(id)
            is Work work
                ? TypedResults.Ok(work)
                : TypedResults.NotFound();
    }

    public static async Task<Results<NoContent, NotFound>> UpdateWorkById(int id, Work work, IWorkService workService)
    {
        var w = await workService.Find(id);

        if (w is null) return TypedResults.NotFound();

        w.Name = work.Name;
        w.TimeStart = work.TimeStart;
        w.TimeEnd = work.TimeEnd;
        w.IsComplete = work.IsComplete;

        await workService.Update(w);

        return TypedResults.NoContent();
    }

    public static async Task<IResult> UpdateWorkByIdWithPatch(int id, WorkDto workDto, IWorkService workService)
    {
        var w = await workService.Find(id);

        if (w is null) return TypedResults.NotFound();

        if (workDto.Name is not null) w.Name = workDto.Name;
        if (workDto.IsComplete is not null) w.IsComplete = workDto.IsComplete.Value;
        if (workDto.TimeStart is not null) w.TimeStart = workDto.TimeStart;
        if (workDto.TimeEnd is not null) w.TimeEnd = workDto.TimeEnd;

        await workService.Update(w);

        return TypedResults.NoContent();
    }

    public static async Task<Results<NoContent, NotFound>> DeleteWorkById(int id, IWorkService workService)
    {
        if (await workService.Find(id) is Work work)
        {
            await workService.Remove(work);
            return TypedResults.NoContent();
        }

        return TypedResults.NotFound();
    }
}

It uses Repository Pattern to perform CRUD operation when API endpoints are called. For this we define an interface by the name of IWorkService as given below.

public interface IWorkService
{
    Task<List<Work>> GetAll();

    Task<List<Work>> GetCompleteWork();

    ValueTask<Work?> Find(int id);

    Task Add(Work w);

    Task Update(Work w);

    Task UpdatePatch(Work w);

    Task Remove(Work w);
}

The class WorkService.cs implements this interface. See code below.

public class WorkService : IWorkService
{
    private readonly WorkDb _dbContext;

    public WorkService(WorkDb dbContext)
    {
        _dbContext = dbContext;
    }

    public async ValueTask<Work?> Find(int id)
    {
        return await _dbContext.Works.FindAsync(id);
    }

    public async Task<List<Work>> GetAll()
    {
        return await _dbContext.Works.ToListAsync();
    }

    public async Task Add(Work work)
    {
        await _dbContext.Works.AddAsync(work);

        await _dbContext.SaveChangesAsync();
    }

    public async Task Update(Work work)
    {
        _dbContext.Works.Update(work);
        await _dbContext.SaveChangesAsync();
    }

    public async Task UpdatePatch(Work work)
    {
        _dbContext.Works.Update(work);
        await _dbContext.SaveChangesAsync();
    }

    public async Task Remove(Work work)
    {
        _dbContext.Works.Remove(work);
        await _dbContext.SaveChangesAsync();
    }

    public Task<List<Work>> GetCompleteWork()
    {
        return _dbContext.Works.Where(w => w.IsComplete == true).ToListAsync();
    }
}

The CRUD operation are performed by calling WorkService.cs” class like:

workService.Add(work); // CREATE RECORD
workService.GetAll() // READ RECORD
workService.Update(w); // UPDATE RECORD
workService.Remove(work) // DELETE RECORD

Performing Unit Testing in ASP.NET Core Minimal API

Unit testing is a software testing technique used to verify the correctness of individual components of an application in isolation. A unit typically represents the smallest testable part of the software, such as a single method, function, or class. The primary objective of unit testing is to ensure that each component performs its intended functionality independently, without relying on external systems such as databases, web services, or file systems. By isolating dependencies through techniques such as mocking or stubbing, developers can focus on validating the business logic of a specific unit.

In ASP.NET Core applications, unit tests are commonly written using testing frameworks such as xUnit. A dedicated test project is created to contain the test cases, and a test runner is used to discover, execute, and report the results of the tests.

Right click on the solution to add a new class project and name it DailyWorkTest. This project will contain the Unit Test cases.

Now add the following packages to this newly added project. These packages are:

• xUnit.net v3
• Microsoft.NET.Test.Sdk
• xunit.runner.visualstudio
• Moq

Lets add unit test cases. So add a new class called WorkUnitTest.cs to this new project. In this class we will define our unit tests. See it’s code below:

public class WorkUnitTest
{
    [Fact]
    public async Task GetWorkByIdIfNotExists()
    {
        // Arrange
        await using var context = new MockDB().CreateDbContext();

        // Act
        var result = await WorkEndpointV1.GetWorkById(1, context);

        Assert.IsType<Results<Ok<Work>, NotFound>>(result);

        var notFoundResult = (NotFound)result.Result;

        Assert.NotNull(notFoundResult);
    }

    [Fact]
    public async Task GetAllWork()
    {
        // Arrange
        await using var context = new MockDB().CreateDbContext();

        context.Works.Add(new Work
        {
            Name = "Test Name 1",
            TimeStart = "Test TimeStart 1",
            TimeEnd = "Test TimeEnd 1",
            IsComplete = false
        });

        context.Works.Add(new Work
        {
            Name = "Test Name 2",
            TimeStart = "Test TimeStart 2",
            TimeEnd = "Test TimeEnd 2",
            IsComplete = true
        });

        await context.SaveChangesAsync();

        // Act
        var result = await WorkEndpointV1.GetAllWork(context);

        //Assert
        Assert.IsType<Ok<Work[]>>(result);

        Assert.NotNull(result.Value);
        Assert.NotEmpty(result.Value);
        Assert.Collection(result.Value, work1 =>
        {
            Assert.Equal(1, work1.Id);
            Assert.Equal("Test Name 1", work1.Name);
            Assert.False(work1.IsComplete);
        }, work2 =>
        {
            Assert.Equal(2, work2.Id);
            Assert.Equal("Test Name 2", work2.Name);
            Assert.True(work2.IsComplete);
        });
    }

    [Fact]
    public async Task GetCompletedWork()
    {
        // Arrange
        await using var context = new MockDB().CreateDbContext();

        context.Works.Add(new Work
        {
            Name = "Test Name 1",
            TimeStart = "Test TimeStart 1",
            TimeEnd = "Test TimeEnd 1",
            IsComplete = false
        });

        context.Works.Add(new Work
        {
            Name = "Test Name 2",
            TimeStart = "Test TimeStart 2",
            TimeEnd = "Test TimeEnd 2",
            IsComplete = true
        });

        await context.SaveChangesAsync();

        // Act
        var result = await WorkEndpointV1.GetCompletedWork(context);

        //Assert
        Assert.IsType<Ok<Work[]>>(result);

        Assert.NotNull(result.Value);
        Assert.NotEmpty(result.Value);
        Assert.Collection(result.Value, w =>
        {
            Assert.Equal(2, w.Id);
            Assert.Equal("Test Name 2", w.Name);
            Assert.True(w.IsComplete);
        });
    }

    [Fact]
    public async Task GetWorkById()
    {
        // Arrange
        await using var context = new MockDB().CreateDbContext();

        context.Works.Add(new Work
        {
            Name = "Test Name",
            TimeStart = "Test TimeStart",
            TimeEnd = "Test TimeEnd",
            IsComplete = false
        });

        await context.SaveChangesAsync();

        // Act
        var result = await WorkEndpointV1.GetWorkById(1, context);

        //Assert
        Assert.IsType<Results<Ok<Work>, NotFound>>(result);

        var okResult = (Ok<Work>)result.Result;

        Assert.NotNull(okResult.Value);
        Assert.Equal(1, okResult.Value.Id);
    }

    [Fact]
    public async Task CreateWork()
    {
        //Arrange
        await using var context = new MockDB().CreateDbContext();

        var newWork = new Work
        {
            Name = "Test Name",
            TimeStart = "Test TimeStart",
            TimeEnd = "Test TimeEnd",
            IsComplete = false
        };

        //Act
        var result = await WorkEndpointV1.CreateWork(newWork, context);

        //Assert
        Assert.IsType<Created<Work>>(result);

        Assert.NotNull(result);
        Assert.NotNull(result.Location);

        Assert.NotEmpty(context.Works);
        Assert.Collection(context.Works, work =>
        {
            Assert.Equal(1, work.Id);
            Assert.Equal("Test Name", work.Name);
            Assert.Equal("Test TimeStart", work.TimeStart);
            Assert.Equal("Test TimeEnd", work.TimeEnd);
            Assert.False(work.IsComplete);
        });
    }

    [Fact]
    public async Task UpdateWork()
    {
        //Arrange
        await using var context = new MockDB().CreateDbContext();

        context.Works.Add(new Work
        {
            Name = "Exiting test name",
            TimeStart = "Test TimeStart",
            TimeEnd = "Test TimeEnd",
            IsComplete = false
        });

        await context.SaveChangesAsync();

        var updatedWork = new Work
        {
            Name = "Updated test name",
            TimeStart = "Updated Test TimeStart",
            TimeEnd = "Updated Test TimeEnd",
            IsComplete = true
        };

        //Act
        var result = await WorkEndpointV1.UpdateWorkById(1, updatedWork, context);

        //Assert
        Assert.IsType<Results<NoContent, NotFound>>(result);

        var noContentResult = (NoContent)result.Result;

        Assert.NotNull(noContentResult);

        var workInDb = await context.Works.FindAsync(1);

        Assert.NotNull(workInDb);
        Assert.Equal("Updated test name", workInDb!.Name);
        Assert.True(workInDb.IsComplete);
    }

    [Fact]
    public async Task UpdateWorkByPatch()
    {
        //Arrange
        await using var context = new MockDB().CreateDbContext();

        context.Works.Add(new Work
        {
            Name = "Exiting test name",
            TimeStart = "Test TimeStart",
            TimeEnd = "Test TimeEnd",
            IsComplete = false
        });

        await context.SaveChangesAsync();

        var updatedWork = new WorkDto
        {
            Name = "Updated test name",
            TimeStart = "Updated Test TimeStart",
            TimeEnd = "Updated Test TimeEnd",
            IsComplete = true
        };

        //Act
        var result = await WorkEndpointV1.UpdateWorkByIdWithPatch(1, updatedWork, context);

        //Assert
        Assert.IsType<NoContent>(result);

        var noContentResult = (NoContent)result;

        Assert.NotNull(noContentResult);

        var workInDb = await context.Works.FindAsync(1);

        Assert.NotNull(workInDb);
        Assert.Equal("Updated test name", workInDb!.Name);
        Assert.True(workInDb.IsComplete);
    }

    [Fact]
    public async Task DeleteWork()
    {
        //Arrange
        await using var context = new MockDB().CreateDbContext();

        var existingWork = new Work     
        {
            Id = 1,
            Name = "Existing test name",
            TimeStart = "Test TimeStart",
            TimeEnd = "Test TimeEnd",
            IsComplete = false
        };

        context.Works.Add(existingWork);

        await context.SaveChangesAsync();

        //Act
        var result = await WorkEndpointV1.DeleteWorkById(existingWork.Id, context);

        //Assert
        Assert.IsType<Results<NoContent, NotFound>>(result);

        var noContentResult = (NoContent)result.Result;

        Assert.NotNull(noContentResult);
        Assert.Empty(context.Works);
    }
}

The above code contains unit test cases written in xUnit that test all the Minimal API endpoints. This includes creation of a new record, reading a record by its id, update a record and delete a record. Test cases when record is not found are also included.

In ASP.NET Core Minimal APIs, TypedResults are preferred over Results because they provide stronger typing, better testability, and automatic API documentation support. While both classes are used to return HTTP responses from API endpoints, TypedResults return specific response types (such as Ok, NotFound, or Created), making the endpoint’s behavior explicit and easier to validate.

One of the main advantages of using TypedResults is improved testability. Since each response has a concrete type, unit tests can directly verify the returned result without relying on generic interfaces or casting. For example, a test can assert that an endpoint returns TypedResults.Ok&RltWork> or TypedResults.NotFound, making the tests more readable, type-safe, and less prone to runtime errors.

See the method GetWorkById that uses TypedResults to return Ok(work) when record is found and NotFound() when record is not available in the database.

public static async Task<Results<Ok<Work>, NotFound>> GetWorkById(int id, WorkDb db)
{
    return await db.Works.FindAsync(id)
        is Work work
            ? TypedResults.Ok(work)
            : TypedResults.NotFound();
}

In it’s Unit Test case given below we assert both OK and NotFound very easily since we used the return type of Results<Ok, NotFound>.

[Fact]
public async Task GetWorkByIdIfNotExists()
{
    // Arrange
    await using var context = new MockDB().CreateDbContext();

    // Act
    var result = await WorkEndpointV1.GetWorkById(1, context);

    Assert.IsType<Results<Ok<Work>, NotFound>>(result);

    var notFoundResult = (NotFound)result.Result;

    Assert.NotNull(notFoundResult);
}

The following code uses the Ok class, and the value’s type is a collection of work.

[Fact]
public async Task GetWorkById()
{
    // Arrange
    await using var context = new MockDB().CreateDbContext();

    context.Works.Add(new Work
    {
        Name = "Test Name",
        TimeStart = "Test TimeStart",
        TimeEnd = "Test TimeEnd",
        IsComplete = false
    });

    await context.SaveChangesAsync();

    // Act
    var result = await WorkEndpointV1.GetWorkById(1, context);

    //Assert
    Assert.IsType<Results<Ok<Work>, NotFound>>(result);

    var okResult = (Ok<Work>)result.Result;

    Assert.NotNull(okResult.Value);
    Assert.Equal(1, okResult.Value.Id);
}

[Fact]
public async Task CreateWork()
{
    //Arrange
    await using var context = new MockDB().CreateDbContext();

    var newWork = new Work
    {
        Name = "Test Name",
        TimeStart = "Test TimeStart",
        TimeEnd = "Test TimeEnd",
        IsComplete = false
    };

    //Act
    var result = await WorkEndpointV1.CreateWork(newWork, context);

    //Assert
    Assert.IsType<Created<Work>>(result);

    Assert.NotNull(result);
    Assert.NotNull(result.Location);

    Assert.NotEmpty(context.Works);
    Assert.Collection(context.Works, work =>
    {
        Assert.Equal(1, work.Id);
        Assert.Equal("Test Name", work.Name);
        Assert.Equal("Test TimeStart", work.TimeStart);
        Assert.Equal("Test TimeEnd", work.TimeEnd);
        Assert.False(work.IsComplete);
    });
}

[Fact]
public async Task UpdateWork()
{
    //Arrange
    await using var context = new MockDB().CreateDbContext();

    context.Works.Add(new Work
    {
        Name = "Exiting test name",
        TimeStart = "Test TimeStart",
        TimeEnd = "Test TimeEnd",
        IsComplete = false
    });

    await context.SaveChangesAsync();

    var updatedWork = new Work
    {
        Name = "Updated test name",
        TimeStart = "Updated Test TimeStart",
        TimeEnd = "Updated Test TimeEnd",
        IsComplete = true
    };

    //Act
    var result = await WorkEndpointV1.UpdateWorkById(1, updatedWork, context);

    //Assert
    Assert.IsType<Results<NoContent, NotFound>>(result);

    var noContentResult = (NoContent)result.Result;

    Assert.NotNull(noContentResult);

    var workInDb = await context.Works.FindAsync(1);

    Assert.NotNull(workInDb);
    Assert.Equal("Updated test name", workInDb!.Name);
    Assert.True(workInDb.IsComplete);
}

Unit Testing using fakes or mock objects

Unit tests should verify the behavior of a single component without depending on external resources such as databases, web services, or file systems. To achieve this isolation, developers use fake or mock objects that replace the real dependencies of the component under test. This approach ensures that the test focuses only on the business logic and produces fast, reliable, and repeatable results.

A fake object is a simplified implementation of a dependency that provides predefined behavior. It is often created manually and is suitable for simple testing scenarios. For example, a fake repository can return hard-coded data instead of retrieving records from a database. While fake objects are easy to understand, they can become difficult to maintain as the number of test cases increases.

A mock object, on the other hand, is created using a mocking framework such as Moq, which is one of the most widely used mocking libraries for .NET applications. Moq allows developers to create mock implementations of interfaces or virtual classes dynamically, eliminating the need to write custom fake classes. Developers can configure mock objects to return specific values, throw exceptions, or verify that certain methods are called with the expected parameters.

In ASP.NET Core applications, Moq is commonly used to mock services, repositories, and other dependencies that are injected through the built-in Dependency Injection (DI) container. During unit testing, the real dependency is replaced with a mock object, allowing the component to be tested independently of external systems. This isolation makes tests deterministic and prevents failures caused by unavailable databases or network services.

One of the key advantages of Moq is its ability to verify interactions between objects. Besides returning predefined results, Moq can confirm that a method was invoked the expected number of times and with the correct arguments. This feature helps ensure that the component under test not only produces the correct output but also interacts correctly with its dependencies.

Using fake or mock objects with the Moq package provides several benefits, including faster test execution, better isolation of business logic, improved reliability, easier maintenance, and greater confidence during code refactoring. As a result, Moq has become a standard tool for writing effective unit tests in ASP.NET Core applications, enabling developers to build high-quality and maintainable software.

Next, add a new class called WorkUnitTestMoq.cs. This class contains test cases for testing with Moq objects. Recall the static class called WorkEndpointV2 contains the custom extension method called WorkAPIV2(). These contains API method that uses WorkService. We will fake this WorkService using Moq objects.

See it’s code below

public class WorkUnitTestMoq
{
    [Fact]
    public async Task GetWorkByIdIfNotExists()
    {
        // Arrange
        var mock = new Mock<IWorkService>();

        mock.Setup(m => m.Find(It.Is<int>(id => id == 1))).ReturnsAsync((Work?)null);

        // Act
        var result = await WorkEndpointV2.GetWorkById(1, mock.Object);

        //Assert
        Assert.IsType<Results<Ok<Work>, NotFound>>(result);

        var notFoundResult = (NotFound)result.Result;

        Assert.NotNull(notFoundResult);
    }

    [Fact]
    public async Task GetAllWork()
    {
        // Arrange
        var mock = new Mock<IWorkService>();

        mock.Setup(m => m.GetAll())
        .ReturnsAsync(new List<Work> {
            new Work
            {
                Id = 1,
                Name = "Test Name 1",
                TimeStart = "Test TimeStart 1",
                TimeEnd = "Test TimeEnd 1",
                IsComplete = false
            },
            new Work
            {
                Id = 2,
                Name = "Test Name 2",
                TimeStart = "Test TimeStart 2",
                TimeEnd = "Test TimeEnd 2",
                IsComplete = true
            }
        });

        // Act
        var result = await WorkEndpointV2.GetAllWork(mock.Object);

        //Assert
        Assert.IsType<Ok<List<Work>>>(result);

        Assert.NotNull(result.Value);
        Assert.NotEmpty(result.Value);
        Assert.Collection(result.Value, work1 =>
        {
            Assert.Equal(1, work1.Id);
            Assert.Equal("Test Name 1", work1.Name);
            Assert.False(work1.IsComplete);
        }, work2 =>
        {
            Assert.Equal(2, work2.Id);
            Assert.Equal("Test Name 2", work2.Name);
            Assert.True(work2.IsComplete);
        });
    }

    [Fact]
    public async Task GetCompletedWork()
    {
        // Arrange
        var mock = new Mock<IWorkService>();

        mock.Setup(m => m.GetCompleteWork())
        .ReturnsAsync(new List<Work> {
            new Work
            {
                Id = 2,
                Name = "Test Name 2",
                TimeStart = "Test TimeStart 2",
                TimeEnd = "Test TimeEnd 2",
                IsComplete = true
            }
        });

        // Act
        var result = await WorkEndpointV2.GetCompletedWork(mock.Object);

        //Assert
        Assert.IsType<Ok<List<Work>>>(result);

        Assert.NotNull(result.Value);
        Assert.NotEmpty(result.Value);
        Assert.Collection(result.Value, w =>
        {
            Assert.Equal(2, w.Id);
            Assert.Equal("Test Name 2", w.Name);
            Assert.True(w.IsComplete);
        });
    }

    [Fact]
    public async Task GetWorkById()
    {
        // Arrange
        var mock = new Mock<IWorkService>();

        mock.Setup(m => m.Find(It.Is<int>(id => id == 1)))
        .ReturnsAsync(new Work
        {
            Id = 1,
            Name = "Test Name 1",
            TimeStart = "Test TimeStart 1",
            TimeEnd = "Test TimeEnd 1",
            IsComplete = false
        });

        // Act
        var result = await WorkEndpointV2.GetWorkById(1, mock.Object);

        //Assert
        Assert.IsType<Results<Ok<Work>, NotFound>>(result);

        var okResult = (Ok<Work>)result.Result;

        Assert.NotNull(okResult.Value);
        Assert.Equal(1, okResult.Value.Id);
    }

    [Fact]
    public async Task CreateWork()
    {
        //Arrange
        var works = new List<Work>();

        var mock = new Mock<IWorkService>();

        var newWork = new Work
        {
            Id = 1,
            Name = "Test Name",
            TimeStart = "Test TimeStart",
            TimeEnd = "Test TimeEnd",
            IsComplete = false
        };

        mock.Setup(m => m.Add(It.Is<Work>(t => t.Name == newWork.Name && t.TimeStart == newWork.TimeStart && t.TimeEnd == newWork.TimeEnd && t.IsComplete == newWork.IsComplete)))
        .Callback<Work>(a => works.Add(a))
        .Returns(Task.CompletedTask);

        //Act
        var result = await WorkEndpointV2.CreateWork(newWork, mock.Object);

        //Assert
        Assert.IsType<Created<Work>>(result);

        Assert.NotNull(result);
        Assert.NotNull(result.Location);

        Assert.NotEmpty(works);
        Assert.Collection(works, work =>
        {
            Assert.Equal(1, work.Id);
            Assert.Equal("Test Name", work.Name);
            Assert.Equal("Test TimeStart", work.TimeStart);
            Assert.Equal("Test TimeEnd", work.TimeEnd);
            Assert.False(work.IsComplete);
        });
    }

    [Fact]
    public async Task UpdateWork()
    {
        //Arrange
        var mock = new Mock<IWorkService>();

        var existingWork = new Work
        {
            Name = "Exiting test name",
            TimeStart = "Test TimeStart",
            TimeEnd = "Test TimeEnd",
            IsComplete = false
        };

        var updatedWork = new Work
        {
            Name = "Updated test name",
            TimeStart = "Updated Test TimeStart",
            TimeEnd = "Updated Test TimeEnd",
            IsComplete = true
        };

        mock.Setup(m => m.Find(It.Is<int>(id => id == 1)))
        .ReturnsAsync(existingWork);

        mock.Setup(m => m.Update(It.Is<Work>(t => t.Name == updatedWork.Name && t.TimeStart == updatedWork.TimeStart && t.TimeEnd == updatedWork.TimeEnd && t.IsComplete == updatedWork.IsComplete)))
            .Callback<Work>(w => updatedWork = w)
            .Returns(Task.CompletedTask);

        //Act
        var result = await WorkEndpointV2.UpdateWorkById(1, updatedWork, mock.Object);

        //Assert
        Assert.IsType<Results<NoContent, NotFound>>(result);

        var noContentResult = (NoContent)result.Result;

        Assert.NotNull(noContentResult);

        var work = await WorkEndpointV2.GetWorkById(1, mock.Object);
        var okResult = (Ok<Work>)work.Result;

        Assert.NotNull(work);
        Assert.Equal("Updated test name", okResult.Value.Name);
        Assert.True(okResult.Value.IsComplete);
    }

    [Fact]
    public async Task UpdateWorkByPatch()
    {
        //Arrange
        var mock = new Mock<IWorkService>();

        var existingWork = new Work
        {
            Id = 1,
            Name = "Exiting test name",
            TimeStart = "Test TimeStart",
            TimeEnd = "Test TimeEnd",
            IsComplete = false
        };

        var updatedWork = new WorkDto
        {
            Name = "Updated test name",
            TimeStart = "Updated Test TimeStart",
            TimeEnd = "Updated Test TimeEnd",
            IsComplete = true
        };

        mock.Setup(m => m.Find(It.Is<int>(id => id == 1)))
        .ReturnsAsync(existingWork);

        mock.Setup(m => m.UpdatePatch(It.Is<Work>(t =>
                t.Name == updatedWork.Name &&
                t.TimeStart == updatedWork.TimeStart &&
                t.TimeEnd == updatedWork.TimeEnd &&
                t.IsComplete == updatedWork.IsComplete)))
                .Callback<Work>(w =>
                {
                    // copy fields from Work to WorkDto for later assertions
                    updatedWork.Name = w.Name;
                    updatedWork.TimeStart = w.TimeStart;
                    updatedWork.TimeEnd = w.TimeEnd;
                    updatedWork.IsComplete = w.IsComplete;
                })
                .Returns(Task.CompletedTask);

        //Act
        var result = await WorkEndpointV2.UpdateWorkByIdWithPatch(1, updatedWork, mock.Object);

        //Assert
        Assert.IsType<NoContent>(result);

        var noContentResult = (NoContent)result;

        Assert.NotNull(noContentResult);

        var work = await WorkEndpointV2.GetWorkById(1, mock.Object);
        var okResult = (Ok<Work>)work.Result;

        Assert.NotNull(work);
        Assert.Equal("Updated test name", okResult.Value.Name);
        Assert.True(okResult.Value.IsComplete);
    }

    [Fact]
    public async Task DeleteWork()
    {
        //Arrange
        var mock = new Mock<IWorkService>();

        var existingWork = new Work
        {
            Id = 1,
            Name = "Existing test name",
            TimeStart = "Test TimeStart",
            TimeEnd = "Test TimeEnd",
            IsComplete = false
        };

        var works = new List<Work> { existingWork };

        mock.Setup(m => m.Find(It.Is<int>(id => id == existingWork.Id)))
        .ReturnsAsync(existingWork);

        mock.Setup(m => m.Remove(It.Is<Work>(t => t.Id == 1)))
            .Callback<Work>(t => works.Remove(t))
            .Returns(Task.CompletedTask);

        //Act
        var result = await WorkEndpointV2.DeleteWorkById(existingWork.Id, mock.Object);

        //Assert
        Assert.IsType<Results<NoContent, NotFound>>(result);

        var noContentResult = (NoContent)result.Result;

        Assert.NotNull(noContentResult);
        Assert.Empty(works);
    }
}

In place of WorkService object we fake it with a Moq object:

var mock = new Mock<IWorkService>();

We then use this fake object in test cases like:

mock.Setup(m => m.Find(It.Is<int>(id => id == 1))).ReturnsAsync((Work?)null);
var result = await WorkEndpointV2.GetWorkById(1, mock.Object);

It.Is(id => id == 1) is an argument matcher that tells Moq to apply this configuration only when the Find() method is called with the value 1.

See the code of GetAllWork() test case where Moq object returns 2 work records whenever the WorkService needs to be called.

var mock = new Mock<IWorkService>();

mock.Setup(m => m.GetAll())
.ReturnsAsync(new List<Work> {
    new Work
    {
        Id = 1,
        Name = "Test Name 1",
        TimeStart = "Test TimeStart 1",
        TimeEnd = "Test TimeEnd 1",
        IsComplete = false
    },
    new Work
    {
        Id = 2,
        Name = "Test Name 2",
        TimeStart = "Test TimeStart 2",
        TimeEnd = "Test TimeEnd 2",
        IsComplete = true
    }
});

var result = await WorkEndpointV2.GetAllWork(mock.Object);

In the Test Explorer run all the test and they all passed successfully. See it’s image below.

Integration Tests in ASP.NET Core Minimal API

Integration tests evaluate how different components of an application work together, providing broader coverage than unit tests. While unit tests focus on isolated pieces of code—such as individual methods or classes—integration tests verify that multiple components interact correctly to produce the expected outcome. In some cases, they test the complete workflow required to process a request from start to finish.

Because of their broader scope, integration tests validate the application’s infrastructure and overall framework. They often involve real components such as:

• Databases
• File systems
• Network services
• The request-response pipeline

Integration tests:

1. Use the same components that the application relies on in production.
2. Require more code execution and data processing.
3. Take longer to run due to their broader scope.

For this reason, integration tests should be reserved for the most critical infrastructure scenarios. Whenever a behavior can be validated with either a unit test or an integration test, prefer a unit test because it is faster, simpler, and more focused.

Integration testing in ASP.NET Core requires the following components:

• A test project that contains and executes the integration tests. This project references the System Under Test (SUT).
• A test web host and test server client that host the SUT and send HTTP requests while receiving responses.
• A test runner to execute the tests and report the results.

Integration tests typically follow the standard Arrange, Act, Assert (AAA) pattern:

1. Configure the SUT’s test web host.
2. Create a test server client to communicate with the application.
3. Arrange: Prepare the test data and HTTP request.
4. Act: Send the request and capture the response.
5. Assert: Verify that the actual response matches the expected result.
6. Repeat the process until all tests have been executed.
7. Generate and report the test results.

The test web host is usually configured differently from the application’s production host. For example, integration tests often use a separate database, custom configuration settings, or mocked external services to provide a controlled testing environment.

The Microsoft.AspNetCore.Mvc.Testing package simplifies integration testing by providing the infrastructure needed to host and test an ASP.NET Core application. It manages the test web host and the in-memory TestServer, reducing the amount of setup code required.

Key features of the package include:

• Copies the SUT’s dependency (.deps) file to the test project’s output directory.
• Sets the content root to the SUT’s project directory so that static files, Razor pages, and views are available during testing.
• Provides the WebApplicationFactory class, which simplifies bootstrapping the application with TestServer.

Creating a new Project for Integration Test

We create a new Class Project called IntegrationTest. Here we will write our Integration Tests for the Minimal API. First of all add the following 4 packages to this project:

• Microsoft.AspNetCore.Mvc.Testing
• xunit.v3
• xunit.runner.visualstudio
• Microsoft.NET.Test.Sdk
• Microsoft.EntityFrameworkCore.Sqlite

Since the integration tests will use SQLite database so we have added Microsoft.EntityFrameworkCore.Sqlite package which is SQLite database provider for Entity Framework Core.

Create a new folder called “Helpers”, to this folder a new class called TestWebApplicationFactory.cs. This class is a custom test host factory for ASP.NET Core integration tests. Its primary job is to replace the application’s normal database configuration with a test database and ensure that database starts in a clean state before tests run.

public class TestWebApplicationFactory<TProgram>
    : WebApplicationFactory<TProgram> where TProgram : class
{
    protected override IHost CreateHost(IHostBuilder builder)
    {
        builder.ConfigureServices(services =>
        {
            services.RemoveAll<IDbContextOptionsConfiguration<WorkDb>>();

            // Register WorkDb for tests using Sqlite. Do not call UseInternalServiceProvider; let EF manage its service provider.
            services.AddDbContext<WorkDb>((serviceProvider, options) =>
            {
                var path = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
                options.UseSqlite($"Data Source={Path.Join(path, "Integration_tests.db")}");
            });

            // Build the provider
            var serviceProvider = services.BuildServiceProvider();

            // Create a scope
            using var scope = serviceProvider.CreateScope();

            var context = scope.ServiceProvider.GetRequiredService<WorkDb>();
            context.Database.EnsureDeleted(); // Ensure a clean database for each test run
            context.Database.EnsureCreated(); // Ensure the database is created
        });

        return base.CreateHost(builder);
    }
}

TestWebApplicationFactory is a custom integration test factory that extends WebApplicationFactory to configure the application specifically for testing. When the test host is created, it replaces the application’s existing WorkDb database configuration with a SQLite database stored in a local file, preventing tests from using the production database. It then builds a temporary service provider to obtain a WorkDb instance, deletes any existing test database, and recreates it to ensure a clean, consistent database state before the application starts. This allows integration tests to run against an isolated database with a predictable schema and no leftover data from previous test runs.

Notice it remove the existing database configuration.

services.RemoveAll<IDbContextOptionsConfiguration<WorkDb>>();

Then registers a SQLite test database.

services.AddDbContext<WorkDb>((serviceProvider, options) =>
{
    var path = Environment.GetFolderPath(
        Environment.SpecialFolder.LocalApplicationData);

    options.UseSqlite(
        $"Data Source={Path.Join(path, "Integration_tests.db")}");
});

Deletes and then recreates a fresh database copy.

context.Database.EnsureDeleted();
context.Database.EnsureCreated();

Test starts
      │
      ▼
CreateHost()
      │
      ▼
Remove production WorkDb configuration
      │
      ▼
Register SQLite WorkDb
      │
      ▼
Delete Integration_tests.db
      │
      ▼
Create new Integration_tests.db
      │
      ▼
Build ASP.NET Core application
      │
      ▼
Tests run against clean SQLite database

WorkEndpointsV1Tests.cs containing the 2 integration tests.

[Collection("Sequential")]
public class WorkEndpointsV1Tests : IClassFixture<TestWebApplicationFactory<Program>>
{
    private readonly TestWebApplicationFactory<Program> _factory;
    private readonly HttpClient _httpClient;

    public WorkEndpointsV1Tests(TestWebApplicationFactory<Program> factory)
    {
        _factory = factory;
        _httpClient = factory.CreateClient();
    }

    public static IEnumerable<object[]> InvalidWorks => new List<object[]>
    {
        new object[] { new WorkDto { Name = "", TimeStart = "Test Time Start", TimeEnd = "Test Time End", IsComplete = false }, "Name is empty" },
        new object[] { new WorkDto { Name = "no", TimeStart = "Test Time Start", TimeEnd = "Test Time End", IsComplete = false }, "Name length < 3" }
    };

    [Theory]
    [MemberData(nameof(InvalidWorks))]
    public async Task PostWorkWithValidationProblems(WorkDto work, string errorMessage)
    {
        var response = await _httpClient.PostAsJsonAsync("/works/v1", work);

        Assert.Equal(HttpStatusCode.BadRequest, response.StatusCode);

        var problemResult = await response.Content.ReadFromJsonAsync<HttpValidationProblemDetails>();

        Assert.NotNull(problemResult?.Errors);
        Assert.Collection(problemResult.Errors, (error) => Assert.Equal(errorMessage, error.Value.First()));
    }

    [Fact]
    public async Task PostWorkWithValidParameters()
    {
        using (var scope = _factory.Services.CreateScope())
        {
            var db = scope.ServiceProvider.GetService<WorkDb>();
        }

        var response = await _httpClient.PostAsJsonAsync("/works/v1", new WorkDto
        {
            Name = "Test Name",
            TimeStart = "Test Time Start",
            TimeEnd = "Test Time End",
            IsComplete = false
        });

        Assert.Equal(HttpStatusCode.Created, response.StatusCode);

        var works = await _httpClient.GetFromJsonAsync<List<Work>>("/works/v1");

        Assert.NotNull(works);
        Assert.Single(works);

        Assert.Collection(works, (work) =>
        {
            Assert.Equal("Test Name", work.Name);
            Assert.Equal("Test Time Start", work.TimeStart);
            Assert.Equal("Test Time End", work.TimeEnd);
            Assert.False(work.IsComplete);
        });
    }
}

WorkEndpointsV1Tests is an integration test class that verifies the behavior of the version 1 Work API endpoints by interacting with a running instance of the application created by TestWebApplicationFactory. The class uses xUnit’s IClassFixture to share a single test application instance and HttpClient to send HTTP requests to the API, closely simulating real client interactions. The [Collection(“Sequential”)] attribute ensures that the tests execute sequentially, preventing conflicts caused by sharing the same SQLite test database. The test suite validates both successful and unsuccessful API behavior: parameterized tests ([Theory]) verify that invalid input data returns a 400 Bad Request response with the expected validation errors, while functional tests ([Fact]) confirm that valid requests create new work items, return a 201 Created response, and persist the data correctly by retrieving and verifying it through the API. This approach ensures that endpoint routing, request validation, database interaction, and response generation all work together as expected in an end-to-end testing environment.

We also add another class called WorkEndpointsV2Tests.cs whose work is to test the version 2 Work API endpoints. This class is very similar to the previous class. It’s code is given below.

[Collection("Sequential")]
public class WorkEndpointsV2Tests : IClassFixture<TestWebApplicationFactory<Program>>
{
    private readonly TestWebApplicationFactory<Program> _factory;
    private readonly HttpClient _httpClient;

    public WorkEndpointsV2Tests(TestWebApplicationFactory<Program> factory)
    {
        _factory = factory;
        _httpClient = factory.CreateClient();
    }

    public static IEnumerable<object[]> InvalidWorks => new List<object[]>
    {
        new object[] { new WorkDto { Name = "", TimeStart = "Test Time Start", TimeEnd = "Test Time End", IsComplete = false }, "Name is empty" },
        new object[] { new WorkDto { Name = "no", TimeStart = "Test Time Start", TimeEnd = "Test Time End", IsComplete = false }, "Name length < 3" }
    };

    [Theory]
    [MemberData(nameof(InvalidWorks))]
    public async Task PostWorkWithValidationProblems(WorkDto work, string errorMessage)
    {
        var response = await _httpClient.PostAsJsonAsync("/works/v2", work);

        Assert.Equal(HttpStatusCode.BadRequest, response.StatusCode);

        var problemResult = await response.Content.ReadFromJsonAsync<HttpValidationProblemDetails>();

        Assert.NotNull(problemResult?.Errors);
        Assert.Collection(problemResult.Errors, (error) => Assert.Equal(errorMessage, error.Value.First()));
    }

    [Fact]
    public async Task PostWorkWithValidParameters()
    {
        using (var scope = _factory.Services.CreateScope())
        {
            var db = scope.ServiceProvider.GetService<WorkDb>();
        }

        var response = await _httpClient.PostAsJsonAsync("/works/v2", new WorkDto
        {
            Name = "Test Name",
            TimeStart = "Test Time Start",
            TimeEnd = "Test Time End",
            IsComplete = false
        });

        Assert.Equal(HttpStatusCode.Created, response.StatusCode);

        var works = await _httpClient.GetFromJsonAsync<List<Work>>("/works/v2");

        Assert.NotNull(works);
        Assert.Single(works);

        Assert.Collection(works, (work) =>
        {
            Assert.Equal("Test Name", work.Name);
            Assert.Equal("Test Time Start", work.TimeStart);
            Assert.Equal("Test Time End", work.TimeEnd);
            Assert.False(work.IsComplete);
        });
    }
}

It’s time we run the Integration tests in the Test Explorer and congrats they all pass. Check the below image.

You can download the source codes by clicking the button:

Download

Organizing Test Projects

Keep unit tests and integration tests in separate projects. This separation offers several benefits:

• Prevents integration testing infrastructure from being included in unit test projects.
• Makes it easier to run unit tests or integration tests independently.
• Improves project organization and maintainability.

Conclusion

In this tutorial we learned how to perform Unit and Integration test for ASP.NET Core Minimal APIs. We covered almost all aspects of testing and hope our efforts are satisfactory. If you have any questions then feel free to use the comment’s section below.

The post How to perform Unit and Integration Testing in Minimal APIs appeared first on YogiHosting.

]]>

Uses of Filters:

• Validate input data
• Log requests and responses
• Check authentication or authorization
• Modify request or response data
• Handle exceptions
• Execute common logic for multiple endpoints

Execution Flow

Client Request
      │
      ▼
Endpoint Filter (Before)
      │
      ▼
Route Handler
      │
      ▼
Endpoint Filter (After)
      │
      ▼
Client Response

How to use filters in Minimal API

We use AddEndpointFilter extension method. To this method we provide a Delegate that fulfills two core roles:

1. It receives the execution context: EndpointFilterInvocationContext
2. It returns the next step in the pipeline: EndpointFilterDelegate

EndpointFilterInvocationContext: Provides direct access to the current request’s HttpContext and exposes an Arguments list.

Arguments List: Contains the arguments passed to the route handler. These arguments are structured in the exact order in which they appear in the handler’s declaration. A classic example is given on official Microsoft docs, check below:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

string ColorName(string color) => $"Color specified: {color}!";

app.MapGet("/colorSelector/{color}", ColorName)
    .AddEndpointFilter(async (invocationContext, next) =>
    {
        var color = invocationContext.GetArgument<string>(0);

        if (color == "Red")
        {
            return Results.Problem("Red not allowed!");
        }
        return await next(invocationContext);
    });

app.Run();

Here we have defined the endpoint handler.

string ColorName(string color) => $"Color specified: {color}!";

This is a simple method that accepts a string parameter. If the endpoint executes successfully, it returns:

Color specified: Blue!

or

Color specified: Green!

depending on the URL.

Map the endpoint:

app.MapGet("/colorSelector/{color}", ColorName)

This creates a GET endpoint.

Example URLs:

GET /colorSelector/Blue
GET /colorSelector/Green
GET /colorSelector/Red

The {color} part is a route parameter. For example:

/colorSelector/Blue

binds.

color = "Blue"

and passes it to:

ColorName(color)

Add an Endpoint Filter:

.AddEndpointFilter(async (invocationContext, next) => {}

This attaches a filter only to this endpoint. Think of the execution order like this:

Request
   ↓
Endpoint Filter
   ↓
Endpoint Handler (ColorName)
   ↓
Response

The filter can:

• inspect arguments
• modify arguments
• stop execution
• modify the response

Read the endpoint argument:

var color = invocationContext.GetArgument<string>(0);

invocationContext contains all arguments passed to the endpoint. The endpoint is:

string ColorName(string color)

Its parameters are:

Index 0 → color

So:

GetArgument<string>(0)

returns the route value. If the URL is:

/colorSelector/Blue

then:

color == "Blue"

Validate the value:

if (color == "Red")
{
    return Results.Problem("Red not allowed!");
}

If the client requests:

GET /colorSelector/Red

the filter immediately returns:

Results.Problem(...)

instead of calling the endpoint. The endpoint handler never executes. The client receives a response similar to:

{
    "title": "An error occurred.",
    "detail": "Red not allowed!"
}

Continue to the endpoint:

return await next(invocationContext);

next() calls the next component in the endpoint pipeline. If there are no more filters, it calls:

ColorName(color)

So:

GET /colorSelector/Blue

executes:

ColorName("Blue")

and returns:

Color specified: Blue!

Multiple Endpoint Filters in Minimal API

We can also add multiple Endpoint Filters to Minimal API. Think of them as layers wrapped around the endpoint, much like nested boxes. Check the below code where you notice that the endpoint itself does almost nothing. The interesting part is the filters attached to it.

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapGet("/", () =>
    {
        app.Logger.LogInformation("             Endpoint");
        return "Test of multiple filters";
    })
    .AddEndpointFilter(async (efiContext, next) =>
    {
        app.Logger.LogInformation("Before 1st filter");
        var result = await next(efiContext);
        app.Logger.LogInformation("After 1st filter");
        return result;
    })
    .AddEndpointFilter(async (efiContext, next) =>
    {
        app.Logger.LogInformation(" Before 2nd filter");
        var result = await next(efiContext);
        app.Logger.LogInformation(" After 2nd filter");
        return result;
    })
    .AddEndpointFilter(async (efiContext, next) =>
    {
        app.Logger.LogInformation("     Before 3rd filter");
        var result = await next(efiContext);
        app.Logger.LogInformation("     After 3rd filter");
        return result;
    });

app.Run();

Map the endpoint.

app.MapGet("/", () =>
{
    app.Logger.LogInformation("             Endpoint");
    return "Test of multiple filters";
})

This creates a GET endpoint for the root URL (/).

When the endpoint finally executes, it:

• Writes “Endpoint” to the log.
• Returns the string:

Test of multiple filters

First Endpoint Filter:

.AddEndpointFilter(async (efiContext, next) =>
{
    app.Logger.LogInformation("Before 1st filter");

    var result = await next(efiContext);

    app.Logger.LogInformation("After 1st filter");

    return result;
})

This filter runs before the endpoint. Before calling next().

app.Logger.LogInformation("Before 1st filter");

prints:

Before first filter

Call next:

await next(efiContext);

This passes execution to the next filter. After that filter (and eventually the endpoint) finishes, execution comes back here. Then:

app.Logger.LogInformation("After 1st filter");

runs:

Second Endpoint Filter:

.AddEndpointFilter(async (efiContext, next) =>
{
    app.Logger.LogInformation(" Before 2nd filter");

    var result = await next(efiContext);

    app.Logger.LogInformation(" After 2nd filter");

    return result;
})

This behaves exactly like the first filter. It surrounds everything after it.

Third Endpoint Filter:

.AddEndpointFilter(async (efiContext, next) =>
{
    app.Logger.LogInformation("     Before 3rd filter");

    var result = await next(efiContext);

    app.Logger.LogInformation("     After 3rd filter");

    return result;
});

This is the last filter.

Calling:

await next(efiContext);

doesn’t invoke another filter because none remain. Instead, it invokes the endpoint.

Execution Order:

Suppose you request:

GET /

Step 1:

The first filter starts.

Before first filter

It calls:

await next()

Step 2:

The second filter starts.

Before 2nd filter

It calls:

await next()

Step 3:

The third filter starts.

Before 3rd filter

It calls:

await next()

Step 4:

No more filters remain, so the endpoint executes.

Endpoint

The endpoint returns:

Test of multiple filters

Step 5:

Execution returns to the third filter.

After 3rd filter

Step 6:

Execution returns to the second filter.

After 2nd filter

Step 7:

Execution returns to the first filter.

After first filter

Final Log Output:

The logs appear in this order:

Before first filter
 Before 2nd filter
     Before 3rd filter
             Endpoint
     After 3rd filter
 After 2nd filter
After first filter

Validations in Minimal API with Filters

As applications grow, validating incoming requests becomes essential to ensure data integrity, application reliability, and security. One effective way to implement validation in Minimal APIs is by using endpoint filters, which allow developers to intercept requests before they reach the endpoint handler. Endpoint filters enable validation logic to be centralized and reused across multiple endpoints, reducing code duplication and improving maintainability.

The below example performs validation with the help of filters.

app.MapPut("/works/{id}", async (int id, Work work, WorkDb db) =>
{
    var todo = await db.Works.FindAsync(id);

    if (todo is null) return Results.NotFound();

    todo.Name = work.Name;
    todo.TimeStart = work.TimeStart;
    todo.TimeEnd = work.TimeEnd;
    todo.IsComplete = work.IsComplete;

    await db.SaveChangesAsync();

    return Results.NoContent();
}).AddEndpointFilter(async (efiContext, next) =>
{
    var w = efiContext.GetArgument<Work>(1);

    var validationError = Utilities.IsValid(w);

    if (!string.IsNullOrEmpty(validationError))
    {
        return Results.Problem(validationError);
    }
    return await next(efiContext);
});

The Work class code:

public class Work
{
    public int Id { get; set; }
     
    public string Name { get; set; }
 
    public string TimeStart { get; set; }
 
    public string TimeEnd { get; set; }
 
    public bool IsComplete { get; set; }
}

After defining the endpoint, the following code attaches an endpoint filter:

.AddEndpointFilter(async (efiContext, next) =>

An endpoint filter executes before and/or after the endpoint handler. It can:

• validate input
• log requests
• authorize users
• measure execution time
• modify responses

In this example, it performs validation.

Accessing the Request Object.

var w = efiContext.GetArgument<Work>(1);

GetArgument() retrieves one of the endpoint handler’s arguments. Here it retrieves the Work object, since Work is the second parameter.

Validating the Object:

var validationError = Utilities.IsValid(w);

The Utilities.IsValid() method performs custom validation on the Work object.

For example, it might check that:

• Name is not empty.
• TimeStart is earlier than TimeEnd.
• Required fields are present.

It returns:

• an error message if validation fails.
• null or an empty string if validation succeeds.

Returning Validation Errors:

if (!string.IsNullOrEmpty(validationError))
{
    return Results.Problem(validationError);
}

If validation fails, the filter stops the request and returns an HTTP error response containing the validation message.

For example:

{
    "title": "An error occurred.",
    "detail": "TimeStart must be earlier than TimeEnd."
}

The endpoint handler is not executed when validation fails.

Calling the Endpoint:

return await next(efiContext);

If validation succeeds, the filter calls the next stage in the pipeline, which executes the endpoint handler.

Execution flow:

HTTP Request
      │
      ▼
Endpoint Filter
      │
      ├── Validation fails
      │       │
      │       ▼
      │  Return Problem()
      │
      └── Validation succeeds
              │
              ▼
      Endpoint Handler
              │
              ▼
      Update Database
              │
              ▼
      Return 204 No Content

Benefits of Using an Endpoint Filter for Validation:

• Separation of concerns: Validation logic is kept separate from the endpoint’s business logic.
• Code reuse: The same validation filter can be applied to multiple endpoints.
• Cleaner handlers: Endpoint methods remain focused on processing valid requests.
• Consistent error handling: All validation failures can return a standardized response format.
• Improved maintainability: Validation rules can be updated in one place without modifying individual endpoints.

Implementing IEndpointFilter interface

Besides being defined as delegates, endpoint filters can also be implemented by creating a class that implements the IEndpointFilter interface. This approach encapsulates the filter logic within a reusable class, making it easier to maintain and apply across multiple endpoints. The following code demonstrates the previous validation filter implemented as a class that implements the IEndpointFilter interface:

public class WorkIsValidFilter : IEndpointFilter
{
    private ILogger _logger;

    public WorkIsValidFilter(ILoggerFactory loggerFactory)
    {
        _logger = loggerFactory.CreateLogger<WorkIsValidFilter>();
    }

    public async ValueTask<object?> InvokeAsync(EndpointFilterInvocationContext efiContext,
        EndpointFilterDelegate next)
    {
        var work = efiContext.GetArgument<Work>(1);

        var validationError = Utilities.IsValid(work!);

        if (!string.IsNullOrEmpty(validationError))
        {
            _logger.LogWarning(validationError);
            return Results.Problem(validationError);
        }
        return await next(efiContext);
    }
}

Filters that implement the IEndpointFilter interface can access services registered in the Dependency Injection (DI) container through constructor injection or service resolution, as demonstrated in the previous example. However, while endpoint filters can use dependencies provided by DI, the filter instances themselves are not resolved directly from the DI container.

The “WorkIsValidFilter” is applied to the following endpoints:

app.MapPut("/works/{id}", async (int id, Work work, WorkDb db) =>
{
    var todo = await db.Works.FindAsync(id);

    if (todo is null) return Results.NotFound();

    todo.Name = work.Name;
    todo.TimeStart = work.TimeStart;
    todo.TimeEnd = work.TimeEnd;
    todo.IsComplete = work.IsComplete;

    await db.SaveChangesAsync();

    return Results.NoContent();
}).AddEndpointFilter<WorkIsValidFilter>(); 

Authentication & Authorization in Minimal API

Authentication verifies the identity of a user before allowing access to an API. Once the user’s identity is established, authorization determines whether the authenticated user has permission to access specific API resources.

In ASP.NET Core, authorization is handled by the IAuthorizationService, which is registered when you call the AddAuthorization extension method.

In the following example, the /hello endpoint is protected by an authorization policy. To access this endpoint, the authenticated user must satisfy two requirements:

1. Belong to the “admin” role.
2. Have a scope claim with the value “head”.

Only users who meet both conditions are authorized to access the /hello resource.

The code below creates a new authorization policy named LevelOne that encapsulates two authorization requirements:

1. A role-based requirement via the RequireRole for users with an admin role.
2. A claim-based requirement via the RequireClaim for which the user must provide a head scope claim.

The LevelOne policy is provided as a required policy to the /hello endpoint:

using Microsoft.Identity.Web;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthorizationBuilder()
  .AddPolicy("LevelOne", policy =>
        policy
            .RequireRole("admin")
            .RequireClaim("scope", "head"));

var app = builder.Build();

app.MapGet("/hello", () => "Hello world!")
  .RequireAuthorization("LevelOne");

app.Run();

Using an Endpoint Filter for Custom Authorization

Filters are useful when you need authorization rules that go beyond the built-in policy system. For example, suppose only the owner of a work item may edit it.

public class OwnerFilter : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext context,
        EndpointFilterDelegate next)
    {
        var httpContext = context.HttpContext;

        if (!httpContext.User.Identity!.IsAuthenticated)
        {
            return Results.Unauthorized();
        }

        var userId = httpContext.User.FindFirst("sub")?.Value;

        var work = context.GetArgument<Work>(1);

        if (work.OwnerId != userId)
        {
            return Results.Forbid();
        }

        return await next(context);
    }
}

Apply the filter:

app.MapPut("/works/{id}", UpdateWork)
    .AddEndpointFilter<OwnerFilter>()
    .RequireAuthorization();

Execution Flow:

Client Request
      │
      ▼
Authentication Middleware
      │
      ▼
Authorization Middleware
      │
      ▼
Endpoint Filter (Custom Rule)
      │
      ▼
Endpoint Handler
      │
      ▼
Database

Best Practice

Use the built-in authentication and authorization system for securing your Minimal APIs. Endpoint filters should complement this system by implementing application-specific rules, such as verifying resource ownership, checking business constraints, or enforcing custom access requirements. This separation keeps your application secure, maintainable, and aligned with ASP.NET Core best practices.

Endpoint filters are a powerful feature of ASP.NET Core Minimal APIs that provide a clean and reusable way to execute logic before and after an endpoint handler. They help separate cross-cutting concerns, such as validation, logging, authentication, authorization, and exception handling, from the core business logic, resulting in cleaner and more maintainable endpoint implementations.

By encapsulating common functionality in filters, developers can reduce code duplication, improve consistency across endpoints, and simplify application maintenance. Whether implemented as delegates for simple scenarios or as classes implementing the IEndpointFilter interface for more complex and reusable functionality, endpoint filters enhance the flexibility, readability, and scalability of Minimal API applications, making them an essential tool for building robust and maintainable web APIs.

The post Filters in ASP.NET Core Minimal API appeared first on YogiHosting.

string return values

The following endpoints return a Hello world text. The 200 status code is returned with text/plain Content-Type header.

app.MapGet("/hello", () => "Hello World");
app.MapGet("/hello", () => Results.Text("Hello World"));

JSON response

The below 2 endpoints return a json with value Hello World. The 200 status code is returned with application/json Content-Type header.

app.MapGet("/hello", () => new { Message = "Hello World" });
app.MapGet("/hello", () => Results.Json(new { Message = "Hello World" }));

Custom Status Code

The endpoint returns a 405 status code.

app.MapGet("/405", () => Results.StatusCode(405));

Internal Server Error

The endpoint returns a 500 status code.

app.MapGet("/500", () => Results.InternalServerError("Something went wrong!"));

Adding and Modifying Headers

Use the HttpResponse object to add or modify response headers:

app.MapGet("/", (HttpContext context) => {
    // Add a custom header
    context.Response.Headers["X-App-Custom-Header"] = "CustomValue";

    // Modify a header called CacheControl
    context.Response.Headers.CacheControl = $"public,max-age=3600";

    return "Hello World";
});

Redirect

app.MapGet("/old-path", () => Results.Redirect("/new-path"));

File

app.MapGet("/download", () => Results.File("somefile.text"));

Stream Response in Minimal API

Instead of downloading the entire response into a string or byte array, we can return a Stream connected to the response body. Using a stream is beneficial because:

1. it avoids loading the entire file into memory.
2. it’s efficient for large files.
3. data can begin flowing to the client immediately.

For example, if the remote server returns:

[
  {
    "name": "Pikachu",
    "type": "Electric"
  }
]

the stream contains those bytes as they arrive.

Check the below code where stream is the response from a minimal api endpoint.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

var proxyClient = new HttpClient();
app.MapGet("/product", async () => 
{
    var stream = await proxyClient.GetStreamAsync("http://flipkart.com/products/saleproducts.json");
    // Proxy the response as JSON
    return Results.Stream(stream, "application/json");
});

app.Run();

In the above code, the last line returns a stream – return Results.Stream(stream, "application/json");.

Results.Stream() creates an HTTP response whose body is the provided stream.

The second parameter:

"application/json"

sets the response’s Content-Type header.

HTTP/1.1 200 OK
Content-Type: application/json

And this is followed by the JSON from the remote server.

When the browser request:

GET http://localhost:5000/product

The sequence is:

Client
   │
   │ GET /product
   ▼
Your ASP.NET API
   │
   │ GET http://flipkart.com/products/saleproducts.json
   ▼
Flipkart Server
   │
   │ JSON Stream
   ▼
Your API
   │
   │ Streams bytes directly
   ▼
Client

The minimal api does not parse or modify the JSON—it simply forwards it.

Without streaming, we might write:

var json = await proxyClient.GetStringAsync("http://flipkart.com/products/saleproducts.json");
return Results.Content(json, "application/json");

This approach:

1. downloads the entire JSON into memory,
2. creates a large string,
3. then sends it to the client.

With Results.Stream:

var stream = await proxyClient.GetStreamAsync(...);
return Results.Stream(stream, "application/json");

The data is forwarded as it is read from the upstream server, making it more memory-efficient, especially for large responses.

Stream a video from Minimal API

Serving large video files can be done by Results.Stream. The below given code streams a video stored in an Azure Blob Storage container to the client.

using Azure.Storage.Blobs;

var builder = WebApplication.CreateBuilder(args);

// Register BlobServiceClient
builder.Services.AddSingleton(_ =>
    new BlobServiceClient(builder.Configuration.GetConnectionString("AzureBlobStorage")));

var app = builder.Build();

app.MapGet("/video/{fileName}", async (string fileName, BlobServiceClient blobServiceClient) =>
{
    // Get the blob container
    var containerClient = blobServiceClient.GetBlobContainerClient("videos");

    // Get the requested blob
    var blobClient = containerClient.GetBlobClient(fileName);

    // Check whether the blob exists
    if (!await blobClient.ExistsAsync())
    {
        return Results.NotFound("Video not found.");
    }

    // Open the blob as a stream
    var stream = await blobClient.OpenReadAsync();

    // Stream the video to the client
    return Results.Stream(
        stream,
        contentType: "video/mp4",
        fileDownloadName: fileName);
});

app.Run();

• A BlobServiceClient is registered with dependency injection.
• The endpoint accepts the video file name as a route parameter.
• The API connects to the videos container in Azure Blob Storage.
• It checks whether the requested blob exists.
• If the blob exists, OpenReadAsync() opens a stream to the blob.
• Results.Stream() streams the video directly to the client without loading the entire file into memory.
• The response uses the video/mp4 content type so browsers and media players can recognize and play the video.

Returning ProblemDetails response from Minimal API

ProblemDetails is a standardized way for a Web API to return error information to clients. It is based on the IETF standard RFC 7807 (now updated by RFC 9457) and is built into ASP.NET Core.

Instead of returning inconsistent error responses like:

{
  "error": "Something went wrong"
}

You return a structured response like:

{
  "type": "https://example.com/errors/not-found",
  "title": "Resource not found",
  "status": 404,
  "detail": "The product with ID 10 does not exist.",
  "instance": "/api/products/10"
}

Properties of ProblemDetails:

IProblemDetailsService is the service responsible for creating and writing ProblemDetails responses in ASP.NET Core. In the Program.cs class, register the Problem Details service with ASP.NET Core’s dependency injection container. It enables your application to produce standardized RFC 9457/RFC 7807 error responses (ProblemDetails) for exceptions and HTTP error status codes.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddProblemDetails();

var app = builder.Build();

app.UseExceptionHandler();
app.UseStatusCodePages();

app.MapGet("/employee/{id:int}", (int id) => id <= 0 ? Results.BadRequest() : Results.Ok(new Employee(id)));

app.Run();

What does AddProblemDetails() do? – It tells ASP.NET Core: “When an error occurs, generate a standardized ProblemDetails response instead of a plain text or HTML error page.”

Without AddProblemDetails() – Suppose an exception occurs by the below code.

app.MapGet("/", () =>
{
    throw new Exception("Database connection failed");
});

The response will be in plain text:

An error occurred while processing your request.

(or an HTML error page (depending on the environment and middleware).)

With AddProblemDetails() – The same exception can produce a JSON response like:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.6.1",
  "title": "An error occurred while processing your request.",
  "status": 500
}

This format is consistent and easier for API clients to consume.

[HttpGet("{id}")]
public IActionResult GetProduct(int id)
{
    var product = repository.Get(id);

    if (product == null)
    {
        return Problem(
            title: "Product not found",
            detail: $"No product exists with ID {id}.",
            statusCode: StatusCodes.Status404NotFound);
    }

    return Ok(product);
}

The response:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.5",
  "title": "Product not found",
  "status": 404,
  "detail": "No product exists with ID 5."
}

You can create one manually:

var problem = new ProblemDetails
{
    Title = "Insufficient Balance",
    Detail = "Your account balance is too low.",
    Status = StatusCodes.Status400BadRequest,
    Type = "https://example.com/errors/insufficient-balance",
    Instance = HttpContext.Request.Path
};

problem.Extensions["errorCode"] = "BAL001";
problem.Extensions["traceId"] = HttpContext.TraceIdentifier;

return BadRequest(problem);

The response:

{
  "type": "https://example.com/errors/insufficient-balance",
  "title": "Insufficient Balance",
  "status": 400,
  "detail": "Your account balance is too low.",
  "instance": "/api/payments",
  "errorCode": "BAL001",
  "traceId": "00-abc123..."
}

We can also return ProblemDetails response with a custom extension. ProblemDetails has an Extensions property, which is a dictionary for adding custom information. Here we’re creating a collection of key-value pairs.

app.MapGet("/customerror", () =>
{
    var ext = new List<KeyValuePair<string, object?>> { new("test", "value") };
    return TypedResults.Problem("This is an error with extensions", extensions: ext);
});

This endpoint defines a GET route at /customerror that returns an RFC 7807 error response.

How it works:

• app.MapGet(“/customerror”, …) registers a GET endpoint that responds to requests made to /problem.
• A collection of extension properties is created containing a single key-value pair:
• Key: “test”
• Value: “value”
• TypedResults.Problem() creates a Problem Details response, which is the standard format for communicating HTTP API errors. The first argument (“This is an error with extensions”) populates the detail property of the response.
• The extensions parameter adds custom fields to the Problem Details payload. These properties appear alongside the standard fields (type, title, status, detail, and instance) and can be used to include additional error information.

A response from this endpoint resembles the following:

{ 
    "type": "about:blank", 
    "title": "An error occurred.", 
    "status": 500, 
    "detail": "This is an error with extensions", 
    "test": "value" 
}

Using the extensions property is useful when clients need additional context, such as correlation IDs, error codes, validation metadata, or other application-specific information, while still conforming to the Problem Details specification.

Customize validation error responses using IProblemDetailsService

IProblemDetailsService is the service responsible for creating and writing ProblemDetails responses in ASP.NET Core. When we call:

builder.Services.AddProblemDetails();

ASP.NET Core registers an implementation of IProblemDetailsService in the dependency injection (DI) container.

Why does it exist? Instead of every middleware or endpoint manually creating a ProblemDetails object, they can delegate the work to IProblemDetailsService. This keeps error handling centralized and consistent.

Think of it like this:

Exception occurs
        │
        ▼
UseExceptionHandler middleware
        │
        ▼
IProblemDetailsService
        │
        ▼
Creates ProblemDetails
        │
        ▼
Writes JSON response

Suppose you have custom middleware. Instead of doing this:

app.Use(async (context, next) =>
{
    try
    {
        await next();
    }
    catch
    {
        context.Response.StatusCode = 500;

        await context.Response.WriteAsJsonAsync(new ProblemDetails
        {
            Title = "Unexpected Error",
            Status = 500
        });
    }
});

You can use IProblemDetailsService.

app.Use(async (context, next) =>
{
    var problemService =
        context.RequestServices.GetRequiredService<IProblemDetailsService>();

    try
    {
        await next();
    }
    catch
    {
        await problemService.TryWriteAsync(new ProblemDetailsContext
        {
            HttpContext = context,
            ProblemDetails = new ProblemDetails
            {
                Title = "Unexpected Error",
                Status = 500
            }
        });
    }
});

Now the response is generated using the same service used throughout the application.

ProblemDetailsContext : TryWriteAsync() accepts a ProblemDetailsContext.

new ProblemDetailsContext
{
    HttpContext = context,
    ProblemDetails = new ProblemDetails
    {
        Title = "Invalid Request",
        Detail = "The supplied data is incorrect.",
        Status = 400
    }
}

The context contains:

• HttpContext
• ProblemDetails
• Exception (optional)
• Additional metadata

Returning File response from Minimal API

In Minimal APIs, the most commonly used approach for returning a file is TypedResults.File. It accepts either a byte[] or a Stream and returns a FileContentHttpResult or FileStreamHttpResult, respectively.

The endpoint defines a Minimal API route that generates a PDF in memory and returns it as a downloadable file.

app.MapGet("/pdfdownload", () =>
{
    // TypedResults.File with a byte[] returns a FileContentHttpResult
    byte[] pdf = GenerateReport();
    return TypedResults.File(pdf, "application/pdf", "work.pdf");
});

Here’s what each part does:

• app.MapGet(“/pdfdownload”, …) registers a GET endpoint at /pdfdownload. When a client sends a GET request to this URL, the lambda expression is executed.
• byte[] pdf = GenerateReport() calls a method that generates the PDF content and returns it as a byte[]. The entire PDF is stored in memory before it is sent to the client.
• TypedResults.File(…) creates a file response from the byte array. Since the input is a byte[], it returns a FileContentHttpResult.

The TypedResults.File method takes three arguments:

1. pdf – The file content as a byte[].
2. “application/pdf” – The MIME type (Content-Type) of the response, which tells the client that the file is a PDF document.
3. “work.pdf” – The suggested filename for the downloaded file. ASP.NET Core includes this value in the Content-Disposition response header so that browsers typically download the file using this name.

When a client requests /pdfdownload, the server generates the PDF, sets the appropriate HTTP headers, and sends the file to the client. Most web browsers will prompt the user to download the file (or open it with a PDF viewer), using work.pdf as the default filename.

This endpoint creates a stream in memory and returns it as a file to the client.

app.MapGet("/filedownload", () =>
{
    // TypedResults.File with a Stream returns a FileStreamHttpResult
    Stream stream = new MemoryStream("Hello, World!"u8.ToArray());
    return TypedResults.File(stream, "application/octet-stream");
});

Here’s how it works:

• app.MapGet(“/download”, …) registers a GET endpoint at /download. The lambda expression runs whenever a client sends a GET request to this URL.
• Stream stream = new MemoryStream(“Hello, World!”u8.ToArray()) creates a MemoryStream containing the text “Hello, World!”.
• “Hello, World!” is a UTF-8 string literal that produces a ReadOnlySpan containing the UTF-8 encoded bytes of the string. .ToArray() converts the span into a byte[].
• new MemoryStream(…) wraps the byte array in a stream so it can be read and sent to the client.
• TypedResults.File(stream, “application/octet-stream”) creates a file response from the stream. Because the input is a Stream, it returns a FileStreamHttpResult.

The TypedResults.File method takes two arguments:

1. stream – The stream containing the file data.
2. “application/octet-stream” – The MIME type of the response. This generic binary content type tells the client that the response contains arbitrary binary data.

Unlike the previous example, this overload does not specify a download filename. As a result, ASP.NET Core doesn’t include a Content-Disposition header with a filename, so the browser determines how to handle the response. Some browsers may display the content, while others may download it with a generated filename.

The Content-Disposition header is an HTTP response header that tells the client (such as a web browser) how the returned content should be handled. It is commonly used to indicate whether a file should be displayed inline or downloaded, and to provide a default filename.

Syntax:

Content-Disposition: disposition-type; filename="filename.ext"

The two most common disposition types are:

1. inline – Display the content in the browser if possible.
2. attachment – Prompt the user to download the file.

Example 1: Download a file

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Disposition: attachment; filename="work.pdf"

Example 2: Display a file in the browser

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Disposition: inline; filename="work.pdf"

When we write:

return TypedResults.File(pdf, "application/pdf", "work.pdf");

ASP.NET Core automatically sets a Content-Disposition header similar to:

Content-Disposition: attachment; filename="work.pdf"

This tells the browser to download the file and use work.pdf as the default filename.

If you omit the filename:

return TypedResults.File(stream, "application/octet-stream");

ASP.NET Core doesn’t set a Content-Disposition header with a filename. The browser then decides how to handle the response based on the content type and its own behavior.

OpenAPI support for File Response

File result types do not automatically add response metadata to the generated OpenAPI document. To ensure the response is accurately described in the OpenAPI specification, you must explicitly provide the required response metadata.

For this we use Produces() method to provide the OpenAPI metadata for the response. This metadata defines the response’s status code, content type, and schema in the generated OpenAPI document. For example we specify content type as “application/pdf” for a pdf file.

We now have added the Produces() method to provide the OpenAPI metadata for the pdf file.

app.MapGet("/pdfdownload", () =>
{
    // TypedResults.File with a byte[] returns a FileContentHttpResult
    byte[] pdf = GenerateReport();
    return TypedResults.File(pdf, "application/pdf", "work.pdf");
})
.Produces(StatusCodes.Status200OK, contentType: "application/pdf");

The .Produces method adds response metadata to the generated OpenAPI document. In this example:

• StatusCodes.Status200OK specifies that the endpoint returns an HTTP 200 OK response.
• contentType: “application/pdf” indicates that the response body is a PDF document.

This metadata allows OpenAPI tools such as Swagger UI to correctly document the endpoint as returning a PDF file.

The generated response section in the OpenAPI document is similar to:

responses:
  "200":
    description: OK
    content:
      application/pdf: {}

Without the .Produces call, the endpoint still returns the PDF correctly at runtime, but the generated OpenAPI document lacks the response metadata needed to accurately describe the file response.

In the same way we have used Produces method for the above second example.

app.MapGet("/filedownload", () =>
{
    // TypedResults.File with a Stream returns a FileStreamHttpResult
    Stream stream = new MemoryStream("Hello, World!"u8.ToArray());
    return TypedResults.File(stream, "application/octet-stream");
})
.Produces<Stream>(contentType: MediaTypeNames.Application.Octet);

For text content, such as CSV or plain text, use contentType: “text/plain”:

app.MapGet("/download/message", () =>
{
    string content = "Hello, World!";

    byte[] bytes = Encoding.UTF8.GetBytes(content);

    // TypedResults.File with byte[] returns FileContentHttpResult
    return TypedResults.File(
        bytes,
        "text/plain",
        "message.txt");
})
.Produces(StatusCodes.Status200OK, contentType: "text/plain");

For CSV or plain text where the response body is a text value, use string as the TResponse for this case and contentType: “text/csv”:

app.MapGet("/users/csv", () =>
{
    string csv = """
                 Id,Name,Email
                 1,John,john@example.com
                 2,Jane,jane@example.com
                 """;

    return csv;
})
.Produces<string>(StatusCodes.Status200OK, contentType: "text/csv");

File Responses for Conditional Requests and Cache Validation

File responses can support HTTP conditional requests to improve caching efficiency. By including cache validation headers such as “ETag” and “Last-Modified”, the server allows clients to determine whether a cached copy of a file is still valid.

When a client makes a request, it can include conditional headers such as If-None-Match (using an ETag) or If-Modified-Since (using a Last-Modified timestamp). The server can use these values to check whether the file has changed.

If the file has not changed, the server returns 304 Not Modified, allowing the client to use its cached copy without downloading the file again. If the file has changed, the server returns 200 OK with the updated file content and updated cache metadata.

In ASP.NET Core Minimal APIs, file results can include ETag and Last-Modified values to provide cache validation information. However, the application must implement the conditional request logic to compare incoming request headers and decide whether to return 304 Not Modified.

Check the below example:

app.MapGet("/shoesale", (
    [FromHeader(Name = "If-None-Match")] string? ifNoneMatch,
    [FromHeader(Name = "If-Modified-Since")] string? ifModifiedSince) =>
{
    byte[] data = File.ReadAllBytes("Products/SaleShoes.json");
    var lastModified = File.GetLastWriteTimeUtc("Products/SaleShoes.json");
    var etag = new EntityTagHeaderValue($"\"{Convert.ToHexString(SHA256.HashData(data))}\"");

    return TypedResults.File(
        data,
        contentType: MediaTypeNames.Application.Json,
        lastModified: lastModified,
        entityTag: etag);
})
.Produces<object>(StatusCodes.Status200OK)
.Produces(StatusCodes.Status304NotModified);

To enable cache validation, a file response from minimal api can include metadata such as:

• ETag: A unique identifier representing a specific version of the resource.
• Last-Modified: The date and time when the resource was last changed.

Clients can send conditional request headers based on this metadata:

• If-None-Match: Contains the previously received ETag value.
• If-Modified-Since: Contains the previously received Last-Modified timestamp.

The server compares the values provided by the client with the current resource metadata:

• If the resource has not changed, the server returns 304 Not Modified without sending the file content. The client uses its cached copy.
• If the resource has changed, the server returns 200 OK with the updated file content and cache validation metadata.

The parameters read request headers sent by the client.

[FromHeader(Name = "If-None-Match")] string? ifNoneMatch,
[FromHeader(Name = "If-Modified-Since")] string? ifModifiedSince)

Reading the JSON file:

byte[] data = File.ReadAllBytes("Products/SaleShoes.json");

Getting the last modified time:

var lastModified = File.GetLastWriteTimeUtc("Products/SaleShoes.json");

Creating an ETag:

var etag = new EntityTagHeaderValue(
    $"\"{Convert.ToHexString(SHA256.HashData(data))}\"");

If SaleShoes.json changes, the hash changes, so the ETag changes.

Returning the file:

return TypedResults.File(
    data,
    contentType: MediaTypeNames.Application.Json,
    lastModified: lastModified,
    entityTag: etag);

The response contains the json file along with Last-Modified and ETag values:

HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: Sat, 11 Jul 2026 10:30:00 GMT
ETag: "A1B2C3D4E5"

The client can store these values for future requests.

OpenAPI metadata:

.Produces<object>(StatusCodes.Status200OK)
.Produces(StatusCodes.Status304NotModified);

The client uses If-None-Match to ask the server:

"I already have the version of this resource identified by this ETag. Send it again only if it has changed."

If the resource hasn’t changed, the server responds with 304 Not Modified instead of sending the resource again.

Step 1: Client requests a resource:

GET /shoesale HTTP/1.1

The server responds with the JSON file and an ETag:

HTTP/1.1 200 OK
Content-Type: application/json
ETag: "A1B2C3D4"

[
  {
    "name": "Running Shoe",
    "price": 50
  }
]

The client stores: The response body and ETag value. Below is an ETag value:

"A1B2C3D4"

Step 2: Client requests the resource again:

GET /shoesale HTTP/1.1
If-None-Match: "A1B2C3D4"

The client is saying:

"I already have version A1B2C3D4. Send me the file only if the current version is different."

Step 3: Server compares the ETag:

The server calculates the current ETag for the file.

Case 1: The file has not changed

Current ETag:

"A1B2C3D4"

Client sent:

"A1B2C3D4"

They match, so the server responds:

HTTP/1.1 304 Not Modified

No response body is sent. The client continues using its cached copy.

Case 2: The file has changed:

Suppose the file was updated.

The server calculates a new ETag:

"F9E8D7C6"

Now Client sends:

"A1B2C3D4"

Server calculates:

"F9E8D7C6"

The ETags do not match, so the server returns:

HTTP/1.1 200 OK
Content-Type: application/json
ETag: "F9E8D7C6"

[
  {
    "name": "Running Shoe",
    "price": 45
  }
]

The client updates its cache with the new file and ETag.

The client is essentially saying:

"Send me this resource only if it has been modified after this date."

If the resource has not changed, the server responds with 304 Not Modified and does not send the resource body again.

1. First request

A client requests a file:

GET /shoesale HTTP/1.1

The server returns the file and includes a Last-Modified header:

HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: Sat, 11 Jul 2026 10:30:00 GMT

[
  {
    "name": "Running Shoe",
    "price": 50
  }
]

The Last-Modified header tells the client:

"This file was last changed at this time."

The client stores:

1. The response body
2. The Last-Modified date

2. Client makes a later request

When the client needs the file again, it sends:

GET /shoesale HTTP/1.1
If-Modified-Since: Sat, 11 Jul 2026 10:30:00 GMT

The client is saying:

"I already have a copy from 10:30. Has it changed since then?"

3. Server checks the modification date

var lastModified = File.GetLastWriteTimeUtc("Products/SaleShoes.json");

Case 1: File has not changed

Client sends:

If-Modified-Since: 10:30

Server file:

Last-Modified: 10:30

The file is unchanged, so the server responds:

HTTP/1.1 304 Not Modified

No file content is sent. The client uses its cached copy.

Case 2: File has changed

Client sends:

If-Modified-Since: 10:30

Server file:

Last-Modified: 11:15

The file is newer, so the server responds:

HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: Sat, 11 Jul 2026 11:15:00 GMT

[
  {
    "name": "Running Shoe",
    "price": 45
  }
]

The client receives the updated file.

File Response for range requests

In ASP.NET Core Minimal APIs, “File result support for range requests” refers to the ability of file-returning endpoints to handle the HTTP Range header automatically. This allows clients to download or stream only a portion of a file instead of the entire file.

This is particularly useful for:

• 🎥 Video and audio streaming
• 📥 Resuming interrupted downloads
• 📄 Reading parts of large files
• 🚀 Reducing bandwidth usage

Without range request support

Suppose you have a Minimal API endpoint:

app.MapGet("/download", () =>
{
    return Results.File(
        "Files/report.pdf",
        "application/pdf");
});

If a client requests:

GET /download HTTP/1.1
Range: bytes=0-999

the server ignores the Range header and returns the entire file is sent.

HTTP/1.1 200 OK
Content-Length: 5000000

Here the entire 5 MB file is sent.

With range request support

ASP.NET Core lets you enable range processing by setting enableRangeProcessing to true.

app.MapGet("/download", () =>
{
    return Results.File(
        path: "Files/report.pdf",
        contentType: "application/pdf",
        enableRangeProcessing: true);
});

Now, if the client requests:

GET /download HTTP/1.1
Range: bytes=0-999

ASP.NET Core automatically:

• Parses the Range header.
• Validates the requested byte range.
• Reads only that portion of the file.
• Returns the correct HTTP response.

The response becomes:

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 0-999/5000000
Content-Length: 1000

Only the first 1000 bytes are sent.

This endpoint exposes a video file through an ASP.NET Core Minimal API and enables HTTP Range Requests, allowing clients (such as browsers or video players) to request only portions of the video.

app.MapGet("/catvideo/{id}", (string id, [FromHeader(Name = "Range")] string? range) =>
{
    var bytes = GetVideo(id);

    return TypedResults.File(
        bytes,
        contentType: "video/mp4",
        fileDownloadName: "cat.mp4",
        enableRangeProcessing: true);
})
.Produces<Stream>(StatusCodes.Status200OK, "video/mp4")
.Produces<Stream>(StatusCodes.Status206PartialContent, "video/mp4")
.Produces(StatusCodes.Status416RangeNotSatisfiable);

Let us understand the code.

1. Mapping the endpoint

app.MapGet("/catvideo/{id}", ...)

Creates a GET endpoint.

Example request:

GET /catvideo/123

Here:

id = "123"

2. Reading the Range header

[FromHeader(Name = "Range")] string? range

This tells ASP.NET Core:

Read the HTTP Range header and bind it to the range parameter.

For example, if the client sends:

GET /catvideo/123 HTTP/1.1
Range: bytes=1000-5000

<p>then</p>

range == "bytes=1000-5000"

If the client doesn’t send a Range header:

GET /catvideo/123

then

range == null

Why isn’t range used? Notice that the code never references the range variable. That’s because:

TypedResults.File(..., enableRangeProcessing: true)

already reads and processes the Range header internally from the HTTP request. The range parameter is therefore optional and is often included only for: logging, debugging, custom validation, or documenting that the endpoint supports range requests.

You could remove it entirely, and range processing would still work.

app.MapGet("/catvideo/{id}",
    (string id,
     [FromHeader(Name = "Range")] string? range,
     ILogger<Program> logger) =>
{
    logger.LogInformation(
        "Video requested. Id: {VideoId}, Range: {Range}",
        id,
        range ?? "<entire file>");

    var bytes = GetVideo(id);

    logger.LogInformation(
        "Serving video '{VideoId}' ({Size} bytes) with range processing {Enabled}.",
        id,
        bytes.Length,
        true);

    return TypedResults.File(
        bytes,
        contentType: "video/mp4",
        fileDownloadName: "cat.mp4",
        enableRangeProcessing: true);
})
.Produces<Stream>(StatusCodes.Status200OK, "video/mp4")
.Produces<Stream>(StatusCodes.Status206PartialContent, "video/mp4")
.Produces(StatusCodes.Status416RangeNotSatisfiable);

3. Loading the video

var bytes = GetVideo(id);

Suppose

byte[] bytes = File.ReadAllBytes("cat.mp4");

Now bytes contains the entire video in memory. For very large videos, using a Stream is generally preferable to avoid loading the whole file into memory.

4. Returning the file

return TypedResults.File(
    bytes,
    contentType: "video/mp4",
    fileDownloadName: "cat.mp4",
    enableRangeProcessing: true);

Each parameter has a purpose:

bytes

The content to send to the client.

contentType

"video/mp4"

Sets the HTTP response header:

Content-Type: video/mp4

So browsers know it’s an MP4 video.

fileDownloadName

"cat.mp4"

This influences the Content-Disposition header. If the browser downloads the file, it suggests the filename cat.mp4.

enableRangeProcessing

true

This is the key setting. It tells ASP.NET Core:

• Look for the Range header.
• Validate the requested byte range.
• Send only the requested bytes if the range is valid.
• Return 206 Partial Content.
• Return 416 Range Not Satisfiable for invalid ranges.
• Include Accept-Ranges: bytes in the response.

Without this flag, the framework would ignore the Range header and return the entire file with 200 OK.

5. Example request without a Range header

Client:

GET /catvideo/123

Response:

200 OK
Content-Type: video/mp4
Content-Length: 52428800

The full 50 MB video is returned.

6. Example request with a Range header

Client:

GET /catvideo/123
Range: bytes=0-999999

The framework sends only the first 1,000,000 bytes.

Response:

206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 0-999999/52428800
Content-Length: 1000000

This is how browsers can start playing a video before downloading the entire file.

7. Invalid Range

Suppose the file size is:

50 MB

but the client requests:

Range: bytes=100000000-200000000

Those byte positions don’t exist.

ASP.NET Core responds:

416 Range Not Satisfiable

along with a Content-Range header indicating the valid total size.

8. The .Produces() calls

These methods don’t change the runtime behavior of the endpoint. Instead, they describe the possible responses for API metadata and OpenAPI/Swagger generation.

Successful full response

.Produces<Stream>(
    StatusCodes.Status200OK,
    "video/mp4")

Documents that the endpoint can return:

200 OK
Content-Type: video/mp4

when the entire file is sent.

In case of Partial response:

.Produces<Stream>(
    StatusCodes.Status206PartialContent,
    "video/mp4")

Documents that the endpoint may return:

206 Partial Content

when it fulfills a valid range request.

In case of Invalid range:

.Produces(
    StatusCodes.Status416RangeNotSatisfiable);

Documents that the endpoint may return:

416 Range Not Satisfiable

for an invalid Range header.

How it all works together

• A client requests /catvideo/123.
• If there is no Range header, ASP.NET Core returns the full video with 200 OK.
• If there is a valid Range header, ASP.NET Core returns only the requested bytes with 206 Partial Content.
• If the range is invalid, it returns 416 Range Not Satisfiable.
• The .Produces() methods advertise these possible responses in the API’s metadata.

This built-in support is what enables smooth seeking in video players and resumable downloads without requiring you to implement byte-range parsing or response handling yourself.

In this tutorial we covered everything related to Responses in Minimal API. Mastering it is an important step toward building high-quality ASP.NET Core applications. Whether you are developing a small project, a RESTful web service, or a large-scale enterprise application, applying the concepts and best practices discussed in this guide will help you create APIs that are performant, scalable, maintainable, and easy for clients to consume. This knowledge forms a strong foundation for developing robust, production-ready web applications using ASP.NET Core Minimal APIs.

The post Complete Guide to Minimal API Response appeared first on YogiHosting.