REST (Representational State Transfer) is an architectural style for designing networked applications that use HTTP requests to perform CRUD (Create, Read, Update, Delete) operations on resources. It relies on a client-server model where resources are identified by URIs, and HTTP methods define the actions to be performed on those resources. REST is stateless, meaning each request from a client to a server must contain all the information necessary to understand and process the request. This simplicity and scalability make REST the most popular architectural style for building web services and APIs in modern web development.

REST and SOAP are both web service protocols but differ significantly in their architecture and implementation. REST is lightweight, uses standard HTTP methods, and is easier to understand and implement, while SOAP is a protocol-based approach with strict XML messaging standards and requires more overhead. REST uses multiple formats (JSON, XML, plain text) for data representation, whereas SOAP exclusively uses XML. REST is stateless and simple to cache, making it ideal for web applications, whereas SOAP supports both stateless and stateful operations with WS-* specifications for security and transactions. REST has become the preferred choice for most modern APIs due to its simplicity, while SOAP is still used in enterprise environments requiring advanced security and transaction support.

HTTP verbs (methods) define the action to be performed on a resource. The primary HTTP verbs used in RESTful APIs are GET, POST, PUT, DELETE, and PATCH, each serving a specific purpose in the CRUD operation lifecycle. GET is used to retrieve data without modifying it, POST creates a new resource, PUT replaces an entire resource, DELETE removes a resource, and PATCH partially updates a resource. Understanding and correctly implementing these methods is crucial for building RESTful APIs that follow best practices and are intuitive for developers to consume.

// GET - Retrieve all users
GET /api/users

// GET - Retrieve a specific user
GET /api/users/1

// POST - Create a new user
POST /api/users
Content-Type: application/json
{
    "name": "John Doe",
    "email": "john@example.com"
}

// PUT - Replace entire user resource
PUT /api/users/1
Content-Type: application/json
{
    "name": "Jane Doe",
    "email": "jane@example.com"
}

// DELETE - Remove a user
DELETE /api/users/1

// PATCH - Partially update user
PATCH /api/users/1
Content-Type: application/json
{
    "email": "newemail@example.com"
}

HTTP status codes are three-digit responses sent by a server to indicate the result of an HTTP request. They are categorized into five classes: 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error). Common codes include 200 (OK), 201 (Created), 204 (No Content), 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), 500 (Internal Server Error), and 503 (Service Unavailable). Proper use of status codes helps clients understand the outcome of their requests and enables better error handling in API consumption. Status codes should be chosen based on the actual result of the server operation to maintain RESTful principles and improve API usability.

REST constraints are guidelines defined by Roy Fielding to ensure an architecture is truly RESTful and scalable. The six main constraints are Client-Server (separation of concerns), Statelessness (each request is independent), Uniform Interface (standardized interaction between components), Cacheability (responses must be cacheable when appropriate), Layered System (client cannot know if directly connected to end server), and Code on Demand (optional, servers can extend client functionality). These constraints promote loose coupling, scalability, and interoperability in distributed systems. Adhering to REST constraints ensures that web APIs are maintainable, scalable, and follow industry best practices for building distributed systems.

Web API and MVC are both ASP.NET frameworks but serve different purposes in application development. MVC (Model-View-Controller) is used to build web applications with user interfaces, returning HTML views to browsers, while Web API is used to build RESTful web services that return data in formats like JSON or XML for consumption by client applications. MVC controllers inherit from Controller class and use action methods to return Views, whereas Web API controllers inherit from ApiController and return data objects that are serialized to JSON/XML. Web API is designed for distributed systems and machine-to-machine communication, while MVC focuses on server-side rendering for human users. In modern .NET applications, these distinctions are often blurred with ASP.NET Core, which unifies both patterns under a single framework.

// MVC Controller - Returns Views (HTML)
public class ProductsController : Controller
{
    public ActionResult Index()
    {
        var products = db.Products.ToList();
        return View(products); // Returns HTML view
    }
}

// Web API Controller - Returns Data (JSON/XML)
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        var products = db.Products.ToList();
        return Ok(products); // Returns JSON data
    }
}

Convention-based routing defines URL patterns centrally in a route configuration (usually in RouteConfig.cs for MVC), applying the same pattern to all controllers and actions following a naming convention. Attribute-based routing, on the other hand, defines routes directly on controller and action methods using attributes like [Route] and [HttpGet], providing more explicit control over URL patterns for each endpoint. Convention-based routing is simpler for large applications with consistent patterns but less flexible for complex scenarios, while attribute-based routing offers granular control and is more readable for understanding endpoint URLs directly in code. Attribute-based routing is the modern approach in ASP.NET Core and is preferred in Web API development for its clarity and flexibility.

Route constraints limit which route patterns can match a URL request by restricting the data type, format, or range of route parameter values. Route constraints are defined using curly braces and constraint syntax (e.g., {id:int}, {name:regex(^[a-z]+$)}) in route templates. Common constraints include int (numeric), string (text), guid (GUID format), min, max, and custom constraints implementing IRouteConstraint. Route constraints improve performance by preventing invalid routes from matching and enhance API security by validating input at the routing level before reaching the action method. They reduce the need for explicit validation in controller actions, making the code cleaner and the API more robust.

Route templates are URL pattern definitions that specify how URLs map to controller actions. They are defined using curly braces to capture variable parameters (e.g., "api/products/{id}") and can include constraints, defaults, and literal segments. Route templates can be defined at the controller level (applying to all actions) or at the individual action level using [Route] attributes. A well-designed route template should be hierarchical, semantic, and consistent across the API, making it easy for developers to understand and predict endpoint URLs. Route templates support optional parameters (using '?'), default values, and variable segments, providing flexibility in designing RESTful API URL structures.

Content negotiation is the mechanism by which a Web API determines the format (JSON, XML, etc.) of the response based on the client's request, specifically the Accept header. When a client sends a request with an Accept header (e.g., "Accept: application/json"), the Web API uses content negotiators to select the appropriate formatter (JsonMediaTypeFormatter, XmlMediaTypeFormatter) to serialize the response. Content negotiation enables a single API endpoint to serve different client types (browsers, mobile apps, third-party integrations) with their preferred data formats without requiring separate endpoints. This promotes API flexibility and reusability. In ASP.NET Core, content negotiation is achieved through MediaTypeFormatters and can be customized to support custom formats if needed.

JSON (JavaScript Object Notation) and XML are both data serialization formats used in Web APIs but differ significantly in structure and performance. JSON uses a lightweight, human-readable format with key-value pairs, arrays, and objects, making it ideal for modern web applications and APIs. XML is a markup language using tags to describe data, offering more verbose structure but better support for complex metadata and attributes. JSON is generally faster to parse, produces smaller payloads, and is natively supported by JavaScript, making it the default choice for most contemporary APIs. XML is more suitable for document-centric data and enterprise integrations where schema validation and complex hierarchies are needed. Most modern Web APIs use JSON as the primary format due to its simplicity, performance, and widespread adoption.

IActionResult is a generic interface representing the result of an action method, allowing flexibility in returning different result types (ObjectResult, BadRequestResult, etc.). ActionResult<T> is a generic wrapper introduced in ASP.NET Core that provides strong typing for the response body while maintaining the benefits of IActionResult, enabling better Swagger/OpenAPI documentation and compiler safety. IActionResult requires explicit casting or type checking when accessing the actual data, whereas ActionResult<T> provides implicit conversion to both T and ActionResult for cleaner code. ActionResult<T> automatically generates proper OpenAPI schema documentation based on the generic type, improving API documentation quality. While both are valid, ActionResult<T> is preferred in modern ASP.NET Core Web APIs for its type safety and improved documentation support.

FromBody, FromQuery, and FromRoute are binding attributes that specify where parameter values should be retrieved from in an HTTP request. FromBody binds data from the request body (typically for POST/PUT requests with JSON/XML payloads), FromQuery extracts data from the URL query string (e.g., "?id=1&name=John"), and FromRoute binds data from the URL path segments (e.g., "/api/users/{id}"). These attributes provide explicit control over model binding and improve code clarity by making the source of each parameter obvious. Using these attributes prevents ambiguity and ensures the ASP.NET runtime binds parameters correctly. They are essential for building APIs with clear contracts and preventing unexpected binding behavior.

[HttpPost("api/users")]
public IActionResult CreateUser([FromBody] UserDto userDto)
{
    // userDto is bound from request body (JSON)
    return CreatedAtAction(nameof(GetUser), new { id = user.Id }, user);
}

[HttpGet("api/users/{id}")]
public IActionResult GetUser([FromRoute] int id)
{
    // id is bound from route parameter
    var user = _repository.GetUser(id);
    return Ok(user);
}

[HttpGet("api/users/search")]
public IActionResult Search([FromQuery] string name, [FromQuery] int? age)
{
    // name and age are bound from query string
    var users = _repository.SearchUsers(name, age);
    return Ok(users);
}

Model validation is the process of ensuring that data received in an API request meets specified constraints and business rules before processing. ASP.NET Web API supports validation through Data Annotations (attributes like [Required], [StringLength], [Range], [EmailAddress]) applied to model properties, which are automatically validated by the framework. The ModelState.IsValid property indicates whether all validation rules have passed, and invalid models can be rejected with a 400 Bad Request response containing error details. Validation prevents invalid data from entering the application, reduces bugs, and provides immediate feedback to API consumers about incorrect requests. Developers can also implement custom validation attributes for complex business logic that standard annotations cannot express.

FluentValidation is a .NET library that provides a fluent, rule-based validation approach as an alternative to Data Annotations for model validation. It allows defining validation rules in a separate validator class using a readable fluent interface (e.g., RuleFor(x => x.Email).NotEmpty().EmailAddress()), keeping validation logic separate from model classes. FluentValidation is more powerful than Data Annotations for complex validation scenarios, supporting conditional rules, cross-property validation, and custom async validators. It integrates seamlessly with ASP.NET Core's dependency injection and model validation pipeline, automatically validating models when they are bound. FluentValidation is preferred in enterprise applications where complex business validation rules require more sophisticated validation frameworks than standard Data Annotations.

Global error handling is a mechanism to catch and handle exceptions across the entire Web API application centrally, rather than in individual action methods. This can be implemented using exception handling middleware, exception filters, or centralized exception handlers. Global error handling ensures consistent error responses, logging, and user-friendly error messages across all endpoints. It improves security by preventing sensitive error details from being exposed to clients and simplifies error management by eliminating repetitive try-catch blocks in controller actions. Implementing global error handling is a best practice that enhances API reliability, maintainability, and provides a consistent error experience for API consumers.

Exception middleware is a custom middleware component that catches unhandled exceptions at the application level in the request pipeline and handles them centrally. It wraps the next middleware in a try-catch block, allowing all exceptions thrown downstream to be caught and processed with consistent error handling and logging. Exception middleware enables you to transform exceptions into standardized error responses, log errors to monitoring systems, and return appropriate HTTP status codes and error messages to clients. It should be placed early in the middleware pipeline to catch exceptions from all subsequent middleware. Implementing exception middleware is a best practice in ASP.NET Core for building robust, maintainable APIs with centralized error handling.

ProblemDetails is a standardized HTTP response format defined in RFC 7807 for communicating API errors to clients in a consistent, machine-readable manner. It includes properties like type, title, status, detail, and instance to provide comprehensive error information. ASP.NET Core natively supports ProblemDetails through the [ApiController] attribute and exception handling middleware, automatically converting exceptions to ProblemDetails responses. Using ProblemDetails standardizes error communication across APIs, improving API usability and allowing clients to parse error responses predictably. The ProblemDetails format is widely adopted in modern REST APIs and is supported by OpenAPI/Swagger documentation tools, making it a best practice for error handling in Web APIs.

Authentication is the process of verifying the identity of a user or client making a request to a Web API. Common authentication mechanisms include API keys, Basic Authentication (username/password in Base64), JWT (JSON Web Tokens), and OAuth 2.0. Authentication establishes who the user is before authorization determines what resources they can access. Web APIs should use secure authentication methods over HTTPS to prevent credential interception. Authentication is typically implemented using middleware in the ASP.NET Core pipeline, which extracts credentials from the request and validates them against a user store. Proper authentication is essential for protecting sensitive API endpoints and ensuring only authorized clients can access them.

JWT (JSON Web Token) Bearer Tokens are a stateless authentication mechanism where the server issues a signed token containing user claims that clients include in the Authorization header of subsequent requests. JWTs consist of three parts: Header (algorithm/type), Payload (claims/data), and Signature (server verification). Bearer tokens are self-contained, eliminating the need for server-side session storage, making them ideal for scalable, distributed systems and mobile applications. The "Bearer" scheme indicates the token type in the Authorization header (e.g., "Authorization: Bearer {token}"). JWTs are secure when transmitted over HTTPS and can include expiration times and role-based claims. They are the most popular authentication mechanism for modern Web APIs due to their simplicity, scalability, and support for OAuth 2.0.

API Keys are simple authentication credentials (usually long strings) that clients include in requests (typically in headers or query parameters) to identify themselves to the API. API Keys are easier to implement than JWT but less flexible, as they don't carry user information and are typically not suitable for user-based authentication. API Keys are commonly used for server-to-server communication, third-party integrations, and public APIs where simplicity is preferred over feature richness. They should be transmitted over HTTPS to prevent interception and should be revocable and rotatable for security. API Keys can be combined with rate limiting to prevent abuse and ensure fair resource usage across clients.

// Custom API Key Authentication Middleware
public class ApiKeyAuthenticationMiddleware
{
    private readonly RequestDelegate _next;

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

    public async Task InvokeAsync(HttpContext context)
    {
        const string apiKeyHeader = "X-API-Key";

        if (!context.Request.Headers.TryGetValue(apiKeyHeader, out var extractedApiKey))
        {
            context.Response.StatusCode = 401;
            await context.Response.WriteAsync("API Key is missing");
            return;
        }

        var appSettings = context.RequestServices.GetRequiredService();
        var apiKey = appSettings.GetValue("ApiKey");

        if (!apiKey.Equals(extractedApiKey))
        {
            context.Response.StatusCode = 401;
            await context.Response.WriteAsync("Unauthorized client");
            return;
        }

        await _next(context);
    }
}

Authorization is the process of determining what authenticated users are allowed to do or access within the API. While authentication verifies who you are, authorization controls what resources and actions you can access based on your identity and roles. ASP.NET Core implements authorization through policies, roles, and claims, allowing fine-grained control over resource access. The [Authorize] attribute on controller actions enforces authorization, and custom authorization policies enable complex business logic for access control. Authorization should be implemented at multiple layers (API endpoints, business logic, data access) for defense-in-depth security. Proper authorization ensures users can only access appropriate resources and perform actions matching their permissions.

The [Authorize] attribute is used to restrict access to controller actions or entire controllers to authenticated users. When applied to an action or controller, it returns a 401 Unauthorized response if the user is not authenticated. The [Authorize] attribute can specify roles or policies to further restrict access (e.g., [Authorize(Roles = "Admin")]). It can be combined with [AllowAnonymous] to exempt specific actions from authorization. The [Authorize] attribute is applied at compile time, making authorization checks automatic and transparent in the request pipeline. Proper use of the [Authorize] attribute is fundamental to securing Web API endpoints and controlling access to sensitive operations.

Authorization policies are named rule sets that define conditions for granting access to resources in ASP.NET Core. Policies are defined in the dependency injection container using policy builders and can check user claims, roles, age, custom requirements, or any custom logic. Policies decouple authorization logic from controllers, making authorization rules centrally manageable and reusable across multiple endpoints. The [Authorize(Policy = "PolicyName")] attribute applies a policy to an action, enabling flexible, maintainable authorization schemes. Custom authorization handlers can implement complex business logic that standard role-based or claim-based checks cannot express. Policies are the recommended approach for authorization in modern ASP.NET Core applications due to their flexibility and maintainability.

CORS (Cross-Origin Resource Sharing) is a security mechanism that allows servers to specify which origins (domain, protocol, port) can access resources from the server. Browsers enforce CORS to prevent malicious websites from making requests to other sites on behalf of users. CORS is configured by adding CORS middleware to the ASP.NET Core pipeline and defining policies that specify allowed origins, HTTP methods, headers, and credentials. Without proper CORS configuration, cross-origin requests from browsers are blocked, preventing legitimate client applications from consuming the API. CORS policies can be configured globally for all endpoints or per-controller/action using the [EnableCors] and [DisableCors] attributes. Proper CORS configuration is essential for APIs consumed by web applications and enables cross-origin communication while maintaining security.

API versioning allows multiple versions of an API to coexist, enabling backward compatibility while introducing breaking changes for new clients. Three main approaches to versioning are URL-based versioning (e.g., "/api/v1/users"), header-based versioning (e.g., "X-API-Version: 1"), and query string versioning (e.g., "?api-version=1"). URL-based versioning is the most explicit and browser-friendly, making version requirements obvious in URLs. Header-based versioning keeps URLs clean but is less visible to browsers and automated tools. Query string versioning provides flexibility but makes URLs less semantic. Each approach has trade-offs; URL-based versioning is most commonly used in RESTful APIs, while header-based versioning is preferred in some enterprise scenarios. Choosing a versioning strategy upfront prevents API compatibility issues and enables smooth evolution of APIs over time.

Swagger/OpenAPI is a specification standard for describing RESTful APIs in a machine-readable format, enabling automated documentation generation, client SDK generation, and API testing. OpenAPI provides a language-agnostic way to define API operations, parameters, responses, security schemes, and data models. Swashbuckle is a popular .NET library that generates OpenAPI specifications from ASP.NET Core Web APIs by analyzing controllers, actions, and model definitions through reflection. Integrating Swagger provides interactive API documentation (Swagger UI) allowing developers to test endpoints directly in the browser without separate testing tools. OpenAPI specifications enable third-party tools to generate client SDKs, perform API validation, and automate documentation, making it an essential tool for modern API development and team collaboration.

// Program.cs - Add Swagger/OpenAPI
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo
    {
        Title = "My API",
        Version = "v1",
        Description = "API for managing products"
    });
});

builder.Services.AddControllers();
var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI(c =>
    {
        c.SwaggerEndpoint("/swagger/v1/swagger.json", "My API v1");
        c.RoutePrefix = string.Empty; // Swagger at root
    });
}

app.MapControllers();
app.Run();

XML documentation comments are comments prefixed with "///" in C# that provide metadata about code elements (classes, methods, properties) and are used by tools like IntelliSense and Swagger to generate documentation. They use XML tags like <summary>, <param>, <returns>, <exception>, and <remarks> to document code behavior, parameters, and return values. In Web API development, XML documentation is extracted by tools like Swashbuckle to generate comprehensive OpenAPI specifications and Swagger UI descriptions. Writing good XML documentation improves code maintainability, provides better IDE IntelliSense support, and generates professional API documentation automatically. XML documentation should be concise yet comprehensive, describing what a method does, its parameters, return values, and any exceptions it might throw.

The middleware pipeline is a series of middleware components in ASP.NET Core that process HTTP requests in sequence, each potentially modifying the request or response before passing it to the next middleware. Middleware is registered in the Program.cs file using app.Use(), app.UseMiddleware(), or built-in extension methods, and the order of registration determines execution order. The request flows through middleware in order, and the response flows back through them in reverse order, creating a nested structure where inner middleware can access modifications made by outer middleware. Understanding the middleware pipeline is crucial for implementing authentication, authorization, logging, error handling, and other cross-cutting concerns. Middleware enables clean, composable code where concerns are separated and reusable across different parts of the application.

IMiddleware is an interface in ASP.NET Core that provides a structured way to create reusable middleware components with dependency injection support. Instead of using inline middleware defined with app.Use() or inline lambdas, IMiddleware-based middleware is implemented as a class with an InvokeAsync method, allowing clear separation of concerns and testability. Middleware implementing IMiddleware can be registered with dependency injection (AddScoped, AddTransient, AddSingleton), enabling injection of services like databases, logging, or configuration. This approach is preferred for complex middleware logic that requires dependencies, as it promotes cleaner, more maintainable code compared to inline middleware. IMiddleware is particularly useful for building reusable middleware libraries that multiple projects can consume.

Filters are components that intercept requests and responses at the action level, allowing you to run code before and after action execution or when exceptions occur. ASP.NET Core supports multiple filter types: Authorization Filters (check permissions), Resource Filters (before/after resource binding), Action Filters (before/after action execution), Exception Filters (handle exceptions), and Result Filters (process action results). Filters can be applied globally, to controllers, or to individual actions, and they execute in a specific order within the action invocation pipeline. Filters are useful for cross-cutting concerns like validation, logging, caching, and error handling at the action level, providing a declarative way to add functionality without modifying action code. While middleware handles application-level concerns, filters are better suited for action-specific logic.

Action Filters execute code immediately before and after an action method is executed, implementing the IActionFilter interface with OnActionExecuting and OnActionExecuted methods. They are useful for modifying action parameters before execution, logging action invocation, measuring execution time, or processing action results. Action Filters can short-circuit action execution by setting the Result property, preventing the action method from running if certain conditions are met. They have access to the ActionExecutingContext and ActionExecutedContext, providing comprehensive information about the request, action, and results. Action Filters are applied using the [Produces], [Consumes], [ServiceFilter], or [TypeFilter] attributes and are commonly used for input validation, output formatting, and performance monitoring.

Exception Filters handle unhandled exceptions thrown by actions or other filters, implementing the IExceptionFilter interface with an OnException method. They are invoked when an exception occurs during action execution, allowing you to transform exceptions into error responses, log errors, or recover from exceptions gracefully. Exception Filters have access to the ExceptionContext, which contains information about the exception and allows setting a result to indicate the error has been handled. They are useful for exception-specific error handling (e.g., returning 404 for NotFound exceptions, 400 for ArgumentException), but middleware-based exception handling is preferred for application-level error handling. Exception Filters work well for action-level or controller-level error handling where different actions might handle specific exceptions differently.

HttpClient is a .NET class used to send HTTP requests to Web APIs and receive responses, providing a modern, asynchronous API for making HTTP calls. HttpClient supports all HTTP methods (GET, POST, PUT, DELETE, PATCH) and handles serialization/deserialization of JSON/XML data automatically when combined with appropriate extensions. Creating a new HttpClient for each request can lead to socket exhaustion and connection pool issues; therefore, IHttpClientFactory is recommended for managing HttpClient instances efficiently. HttpClient should be used with proper error handling, timeouts, and cancellation tokens to prevent hanging requests and resource leaks. Understanding HttpClient is essential for Web API consumers (client applications) that need to call external APIs or other services.

IHttpClientFactory is a factory abstraction in ASP.NET Core that manages HttpClient instances efficiently, preventing socket exhaustion and connection pool issues. It provides three ways to create named or typed HttpClient instances: GetClient (named clients), CreateClient (one-off clients), and typed clients (defined services). IHttpClientFactory automatically manages connection pooling, handler lifetime, and request pipelining, resulting in better performance and resource utilization compared to creating individual HttpClient instances. It integrates seamlessly with dependency injection and middleware, allowing configuration of default headers, base addresses, and handlers per client. Using IHttpClientFactory is a best practice for applications that make multiple HTTP calls to external services or APIs, ensuring efficient resource management and improved application scalability.

Polly is a .NET resilience and transient-fault-handling library that implements patterns like Retry, Circuit Breaker, Timeout, Bulkhead, and Fallback to handle transient failures when calling external services. The Retry policy automatically retries failed requests up to a specified number of times, with optional exponential backoff to avoid overwhelming the service. The Circuit Breaker pattern prevents cascading failures by stopping requests when a service becomes unavailable, allowing it to recover before retrying. Combining multiple policies (Retry + Circuit Breaker + Timeout) creates robust resilience strategies for external service calls. Polly integrates with IHttpClientFactory, allowing resilience policies to be applied to HttpClient instances automatically. Using Polly in distributed systems significantly improves application stability and user experience by gracefully handling transient failures and cascading failures.

// Program.cs - Add Polly resilience policies
var retryPolicy = HttpPolicyExtensions
    .HandleTransientHttpError()
    .OrResult(r => r.StatusCode == System.Net.HttpStatusCode.TooManyRequests)
    .WaitAndRetryAsync(3, retryAttempt =>
        TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));

var circuitBreakerPolicy = HttpPolicyExtensions
    .HandleTransientHttpError()
    .CircuitBreakerAsync(handledEventsAllowedBeforeBreaking: 5,
        durationOfBreak: TimeSpan.FromSeconds(30));

var combinedPolicy = Policy.WrapAsync(retryPolicy, circuitBreakerPolicy);

builder.Services.AddHttpClient("ResilientClient")
    .AddPolicyHandler(combinedPolicy);

// Usage
var client = httpClientFactory.CreateClient("ResilientClient");
var response = await client.GetAsync("https://api.example.com/data");

gRPC (gRPC Remote Procedure Call) is a high-performance, open-source RPC framework developed by Google that uses HTTP/2 and Protocol Buffers for efficient binary serialization and communication. Unlike REST which uses JSON/XML over HTTP/1.1, gRPC provides lower latency, better bandwidth efficiency, and built-in support for streaming and multiplexing. gRPC is ideal for internal service-to-service communication and scenarios requiring high performance, while REST is more suitable for public APIs and browser-based clients. gRPC has a steeper learning curve and requires code generation from .proto files, whereas REST is simpler and requires no code generation. Both technologies can coexist in modern applications; some services use gRPC internally for performance while exposing REST APIs externally for broader accessibility and ease of consumption.

Response caching stores HTTP responses on the client or intermediary proxies to eliminate redundant requests to the server for unchanged data. HTTP caching is controlled through Cache-Control headers that specify caching directives like max-age (cache duration), public (cacheable by proxies), private (cacheable only by client), and no-cache (must validate with server). ASP.NET Core provides the [ResponseCache] attribute to apply caching policies to actions, automatically setting appropriate response headers. Response caching reduces server load, improves response times, and reduces bandwidth usage, significantly improving overall application performance. Proper cache invalidation strategies are essential to prevent serving stale data; cache should only be applied to endpoints with data that doesn't frequently change or when proper cache-busting mechanisms are in place.

Output caching is a server-side caching mechanism that stores the rendered output of action methods in memory or a distributed cache to avoid re-execution for identical requests. Unlike HTTP response caching which is client/proxy-based, output caching operates on the server and can be more aggressive since the server controls cache invalidation. ASP.NET Core's OutputCache middleware enables declaring output caching policies with cache key generation strategies, duration, and invalidation triggers. Output caching is particularly useful for expensive computations, database queries, or frequently accessed endpoints that produce the same output for identical requests. Output caching requires careful implementation to ensure cache keys accurately represent request variations and cache invalidation is triggered appropriately when data changes.

Rate limiting restricts the number of requests a client can make to an API within a specified time period, preventing abuse, ensuring fair resource usage, and protecting against denial-of-service attacks. Common rate limiting strategies include token bucket (fixed request allowance per period), sliding window (time-based allowance), and leaky bucket (fixed request processing rate). Rate limiting can be implemented using middleware, action filters, or third-party libraries like AspNetCoreRateLimit. When a client exceeds the rate limit, the API typically returns a 429 Too Many Requests status code with information about retry timing. Rate limiting is essential for public APIs to prevent resource exhaustion and ensure service availability for all users. Well-designed rate limiting should be transparent to legitimate users while effectively preventing abuse.

Minimal APIs are a lightweight alternative to controller-based Web APIs in .NET 6 and later, allowing you to define HTTP endpoints directly in Program.cs without creating controller classes. Minimal APIs use fluent syntax (app.MapGet, app.MapPost, app.MapPut, app.MapDelete) to define routes, handlers, and dependencies in a concise manner. They are ideal for building microservices, simple APIs, or prototypes where the overhead of traditional controller-based approaches is unnecessary. Minimal APIs support dependency injection, authorization, validation, and middleware just like controller-based APIs but with less boilerplate code. They promote a functional programming style and are particularly useful in serverless environments or scenarios where simplicity and performance are prioritized over convention-based structure.

OData (Open Data Protocol) is a standardized protocol for querying and manipulating data via HTTP, allowing clients to specify complex queries using URL query syntax. OData enables filtering ($filter), sorting ($orderby), pagination ($skip, $top), selecting specific fields ($select), and expanding related entities ($expand) without requiring the server to implement multiple endpoints for each combination. OData is particularly useful for exposing database data to multiple client types with varying query requirements, reducing API endpoint proliferation. ASP.NET Core provides OData libraries that automatically expose EntityFramework DbSets as queryable OData endpoints, enabling powerful data exploration capabilities. OData adds complexity compared to traditional REST APIs but provides significant flexibility for complex query scenarios and is widely adopted in enterprise applications.

GraphQL is a query language and runtime for APIs that allows clients to request exactly the data they need, avoiding over-fetching (requesting unnecessary data) and under-fetching (multiple requests for related data). Unlike REST which returns fixed data structures per endpoint, GraphQL provides a single endpoint where clients specify their data requirements in a query, and the server responds with only that data. GraphQL uses a strongly-typed schema to define data types and relationships, enabling powerful introspection and automatic documentation. GraphQL has advantages in reducing bandwidth usage and request count, but introduces complexity in server implementation, query optimization, and caching. While GraphQL and REST solve different problems, GraphQL is gaining popularity in mobile applications and complex data integration scenarios where bandwidth efficiency and precise data fetching are critical.

Health checks are endpoints that report the status of an application and its dependencies, enabling monitoring tools, load balancers, and orchestration platforms to determine if an instance is healthy and ready to serve traffic. ASP.NET Core provides the Health Checks middleware that exposes a configurable endpoint (typically /health) returning the application's overall health status. Health checks can include database connectivity, external service availability, disk space, memory usage, and custom business logic indicators. Different health check statuses (Healthy, Degraded, Unhealthy) indicate the application's operational state, allowing external systems to make intelligent routing and scaling decisions. Health checks are essential in containerized and cloud-native architectures for service discovery, auto-scaling, and ensuring only healthy instances receive traffic.

IHostedService is an interface for implementing background services that run for the application's lifetime, starting when the application starts and stopping when it stops. Background services (like scheduled tasks, message queue processors, cache warmers) extend BackgroundService and implement ExecuteAsync to perform long-running operations on a separate thread without blocking request processing. Hosted services are registered with dependency injection using AddHostedService and are automatically managed by the ASP.NET Core runtime. They enable background work like data synchronization, periodic tasks, and event handling without requiring external schedulers. IHostedService is ideal for implementing critical background processes that must run with the application lifecycle and can access the same dependencies as regular services.

SignalR is a library for adding real-time bidirectional communication capabilities to ASP.NET Core applications, enabling servers to push updates to connected clients instantly. SignalR automatically handles connection management, reconnection logic, and fallback mechanisms (WebSockets, Server-Sent Events, Long Polling) to maintain compatibility across browsers and networks. It uses hubs (server-side components) and connections (client connections) to facilitate real-time messaging, making it ideal for chat applications, live notifications, collaborative tools, and real-time dashboards. SignalR abstracts the underlying transport protocol complexity, allowing developers to focus on application logic. SignalR is appropriate when you need server-to-client push notifications or real-time two-way communication; for request-response APIs, traditional REST or gRPC are more suitable.

Dependency injection (DI) is a design pattern where objects receive their dependencies from external sources rather than creating them, promoting loose coupling and testability. ASP.NET Core has built-in dependency injection where services are registered in the service container (in Program.cs) and automatically injected into controllers and other services through constructor injection. Services are registered with lifetimes: Transient (new instance each time), Scoped (new instance per request), or Singleton (single instance for application lifetime). DI enables easy unit testing by substituting real implementations with mock objects, improves code maintainability by centralizing configuration, and supports testing and modularity. Proper use of dependency injection is fundamental to building maintainable, testable ASP.NET Core applications.

Async/await is a C# language feature that simplifies asynchronous programming by allowing you to write asynchronous code that reads like synchronous code. In Web APIs, async action methods (returning Task<IActionResult>) enable non-blocking I/O operations like database queries, file access, and HTTP calls, improving server scalability by releasing threads to handle other requests while waiting. The await keyword pauses execution until an asynchronous operation completes, then resumes with the result. Using async/await prevents thread starvation in high-concurrency scenarios and improves resource utilization. Web API actions should be async when performing I/O-bound operations; CPU-bound operations don't benefit from async. Proper async/await usage is essential for building scalable Web APIs that efficiently handle many concurrent requests.

API documentation describes how to use an API, including available endpoints, request/response formats, authentication methods, error codes, and usage examples. Good API documentation is crucial for API adoption, reducing integration time, and enabling third-party developers to build applications on top of your API. Documentation can be manual (written guides) or automated (generated from code using tools like Swagger/OpenAPI). Automated documentation ensures accuracy and stays in sync with code changes, while manual documentation allows for detailed explanations and usage patterns. Well-documented APIs reduce support costs, improve developer experience, and facilitate better integration with external systems. Investing in API documentation is an investment in API quality, usability, and adoption.

Best practices for Web API development include following REST principles (proper HTTP verb usage, meaningful URIs), implementing proper error handling with standardized error responses, securing endpoints with authentication and authorization, validating input thoroughly, documenting APIs comprehensively, implementing versioning for backward compatibility, and using HTTPS for all communication. Additional practices include implementing logging and monitoring, using pagination for large result sets, implementing rate limiting to prevent abuse, designing consistent and intuitive URL structures, implementing caching appropriately, and thoroughly testing APIs with integration and performance tests. Following these practices results in APIs that are secure, maintainable, scalable, and easy for developers to integrate and use. Regular code reviews and architectural decisions should be guided by these best practices to maintain API quality throughout the development lifecycle.