Web API Interview Questions

A client is a program that sends requests, such as a browser or a mobile app. A server is a program that waits for requests and answers them, such as our ASP.NET Core API. In the SMS, the teacher's browser is the client and the API is the server.

An API (Application Programming Interface) is a set of addresses that other programs call to read or change data. A Web API works over HTTP and usually exchanges JSON. For example, GET /api/classes/10/sections/A/students returns the students of Class 10-A.

200 OK means the request worked. 201 Created means something new was saved. 400 Bad Request means the client sent invalid data, 404 Not Found means the item does not exist, and 500 Internal Server Error means the server failed. Codes starting with 2 are success, 4 are client errors, 5 are server errors.

GET reads data, has no body, and is safe to repeat; browsers may cache or bookmark it. POST creates something new and sends data in the body; repeating it can create duplicates. Never change data with GET, because a refresh or a link preview could repeat it.

Stateless means each request stands alone; the server does not remember earlier requests. So every request must carry the caller's identity, usually a token in the Authorization header or a cookie. The API validates that token on every request.

The browser sends a GET request with the class filter and the login token. The API checks the token and the teacher's permission, runs the C# logic, and queries the database for the enrolled students. SQL Server returns the rows, the API converts them to JSON with status 200, and the browser displays the list.

A request has a method and URL, headers, and an optional body. A response has a status line with a status code, headers, and an optional body. For example, POST /api/students with a JSON body got 201 Created, a Location header, and the new student as JSON.

400 Bad Request means the request itself is wrong, such as an empty name; sending it again unchanged fails again. 409 Conflict means the request is valid but clashes with the current state, such as issuing a book with no free copy. 401 means "not signed in"; 403 means "signed in, but not allowed".

The part of a URL after ?, with name=value pairs joined by &. Use the path to identify a resource, such as /api/students/3, and the query string for options on it, such as paging, sorting, or filtering: /api/students?page=2&pageSize=20.

Safe methods change nothing on the server, such as GET. Idempotent methods have the same effect whether sent once or many times: GET, PUT, and DELETE are; POST is not. Deleting student 4 twice returned 204 then 404, but student 4 was gone either way.

PUT replaces the whole resource with the body sent, so missing fields are treated as cleared, and sending it twice gives the same result. PATCH changes only the fields sent; whether it is idempotent depends on the change, such as "add 1" versus "set to 5".

Resources with their own addresses, nouns in paths and verbs in methods, plural collections, children under parents, statelessness, and status codes that report the result. Good: GET /api/students/3/fee-invoices. Bad: POST /api/getFeeInvoicesForStudent?id=3.

Return status codes that match the result: 400 for invalid input, 404 for a missing invoice, 409 for a conflict such as an already-paid invoice, and 2xx only for real success. Put details in a standard error body. Clients that check only the status code then behave correctly without changes.

Make the operation idempotent: the client sends a unique idempotency key with the request, and the server stores it with the payment and returns the first result for any repeat with the same key. Disable the button after the first click too, but never rely on the client alone.

When each request carries everything needed, such as identity in a token and the ids in the URL, any server can handle any request. You can add servers behind a load balancer, restart one without losing sessions, and cache responses. Server-side session state ties users to one machine and limits scaling.

The cross-platform web server built into ASP.NET Core. It runs inside your application, so dotnet run alone can serve HTTP requests. In production it can face the internet directly or sit behind a reverse proxy such as IIS, Nginx, or a cloud load balancer.

Before builder.Build(), services are registered with builder.Services.Add..., such as controllers and OpenAPI. After it, the request pipeline is built with app.Use... and app.Map..., and app.Run() starts the server. Services cannot be added after Build().

A controller is a class, usually deriving from ControllerBase, that handles requests for one resource, with a route such as [Route("api/school")]. An action is a public method in it with an HTTP attribute such as [HttpGet]; it runs for the matching method and path.

It holds launch profiles for running the app on a developer's computer: URLs and ports, and environment variables such as ASPNETCORE_ENVIRONMENT=Development. It is not used in production; servers set the environment and URLs through their own configuration.

ASPNETCORE_ENVIRONMENT sets it, and code checks it with app.Environment.IsDevelopment(), to show tools such as the OpenAPI document only while developing; settings files can differ per environment too. When it is not set, the environment is Production, so development features stay off by default.

UseHttpsRedirection wants to send HTTP requests to HTTPS, but the app has no HTTPS endpoint, for example when started with the http launch profile. It lets the request through and logs the warning. With an HTTPS endpoint configured, HTTP requests get a 307 redirect instead.

That AddControllers() registers controllers and MapControllers() is in the pipeline, that the controller is public with [ApiController] and a [Route], that the action has the right HTTP attribute, and that the URL, including the api/ prefix and port, matches. Logging at Information level for routing shows which endpoint, if any, matched.

The API project holds only HTTP concerns: controllers, middleware, configuration, and the composition root. Business rules and entities live in a core project, and data access in a data project, both referenced by the API. Controllers translate HTTP to service calls and results back to HTTP.

The hosting model: Kestrel directly, behind a reverse proxy, in a container, or on a managed platform, chosen for TLS termination, scaling, and operations needs. In production the environment is Production, development tools such as OpenAPI UIs are off or protected, HTTPS is enforced, URLs come from server configuration, and secrets come from a secure store, never source files.

A step in the request pipeline. Each middleware receives the HttpContext and the next step; it can run code before calling next, stop the request, or run code after the rest of the pipeline returns. Logging, HTTPS redirection, authentication, and error handling are all middleware.

app.Use adds a middleware that receives the next step and normally calls it. app.Run with a delegate adds a terminal step that never calls a next one. app.Map starts a separate branch for a path prefix. (app.Run() with no arguments, at the end of Program.cs, starts the server.)

A middleware writes the response itself and does not call the next step, so the rest of the pipeline, including the controller, never runs. The earlier middleware still run their "after" code. Authentication answering 401, or a stock-taking check answering 503, are examples.

A class whose constructor takes RequestDelegate next (plus singleton services such as a logger) and which has public async Task InvokeAsync(HttpContext context) that calls await _next(context). Register it with app.UseMiddleware<T>(), usually through an extension method such as app.UseRequestTiming().

Once the action starts writing the body, the headers have been sent, and changing them throws "Headers are read-only, response has already started". Set headers before calling next, or register context.Response.OnStarting(...), which runs just before the headers go out.

Exception handling first, so it wraps everything; then HTTPS redirection, static files, routing and CORS, authentication, authorization, and finally the endpoints. Each step needs what the earlier ones did: authorization needs the user that authentication found.

The middleware order: UseAuthorization() placed before UseAuthentication() checks requests before any token has been read, so every caller looks anonymous. Restore the order, document why each middleware sits where it does, and add a test that signs in and calls a protected endpoint.

Not for when the endpoints run: MapControllers() only registers them, and WebApplication runs the endpoint middleware at the end of the pipeline, after every Use... call. A middleware added after MapControllers() still runs before the controller. The order of the Use... calls among themselves still matters.

Middleware for concerns that apply to every HTTP request, even unmatched ones: timing, error handling, security headers, rate limiting. Filters for concerns tied to actions and their metadata: validation, per-action caching, action-level authorization. The action only for logic specific to that endpoint. Keep business rules out of all three, in the core layer.

A controller is a class deriving from ControllerBase, with action methods routed by attributes and services injected through its constructor. A minimal API endpoint is a function mapped in code with app.MapGet and similar, receiving services as parameters. Both run on the same pipeline.

A part of the route template in braces, such as {admissionNumber} in api/students/{admissionNumber}. ASP.NET Core takes that part of the URL and passes it to the action parameter with the same name, converting the type if needed.

405 means the path exists but not for that HTTP method, such as POST to a GET-only route; the Allow header lists the methods that work. 404 means no route matches the path at all.

It makes attribute routing required, returns 400 automatically when model validation fails, applies binding source rules (complex types from the body), and turns error results such as NotFound() into ProblemDetails JSON. Without it, a controller behaves like an MVC controller.

ActionResult<T> lets the action return either a T, which becomes 200 OK, or another result such as NotFound(), with less code. It also keeps the success type visible to tools, so the OpenAPI document describes the response body. IActionResult loses that type information.

[ApiController] converts NotFound() into a ProblemDetails body with type, title, status, and traceId, while the minimal API's Results.NotFound() sends an empty body. To make errors consistent, register ProblemDetails for the whole app so every error uses the same shape.

The action reads the request, calls a service, and turns the result into an HTTP response, such as 200 with a DTO or 404. Business rules, SQL, and entity mapping do not belong there: they go in the core services and the data layer, where they can be tested without HTTP.

Move each resource's endpoints into its own static class with an extension method such as MapStudentEndpoints(this IEndpointRouteBuilder app), using MapGroup("/api/students") for the shared prefix and settings. Move handler bodies into named methods so they can be tested. Program.cs then only calls one Map method per resource.

Weigh the number of endpoints, team experience, the need for filters and conventions, and existing code. Controllers suit large APIs and teams used to them; minimal APIs suit small focused services. Keep endpoints thin and rules in services, use one error format and one validation approach, and the endpoint layer can be rewritten without touching the rest.

A technique where an object receives the services it needs, usually through its constructor, instead of creating them itself. In ASP.NET Core a built-in container creates them: StudentsController asks for a StudentService and gets one, with its repository and DbContext built for it.

Singleton: one object for the whole application. Scoped: one object per request, shared inside it. Transient: a new object every time one is requested. In the demo, the singleton id never changed, the scoped id changed per request, and transient ids differed even within one request.

Scoped, which AddDbContext uses by default. A DbContext tracks the entities of one unit of work and is not thread-safe, so each request needs its own, shared by the repositories and services handling that request, and disposed when the request ends.

A shorter-lived service held by a longer-lived one, such as a singleton whose constructor takes a scoped DbContext: the context then lives forever and is shared by every request. In Development, scope validation stops the app at startup with "Cannot consume scoped service ... from singleton". It is off in Production by default.

Controllers are not registered in the container; ASP.NET Core creates them when a request needs one, resolving their constructor parameters then. So startup validation does not see that a controller's dependency is missing. Tests that call every endpoint catch it before users do.

Constructor injection makes every dependency visible in one place, lets the container validate them, and lets tests pass fakes directly. Resolving from IServiceProvider or HttpContext.RequestServices (the service locator pattern) hides dependencies and couples code to the container.

Singletons that hold per-request state, such as a current-user helper or a cache keyed by nothing, and singletons that capture scoped services. Check registrations for state and lifetimes, make per-request state scoped, keep singletons stateless or thread-safe, and add a concurrency test that runs two users in parallel.

Inject IServiceScopeFactory, create a scope for each piece of work with CreateAsyncScope(), resolve the DbContext or repository from that scope, and dispose the scope when the work ends. Each run then gets a fresh context, as a request would, instead of one captive context for the life of the app.

Each project registers its own types through one extension method, such as AddSchoolData(connection), so the host's Program.cs composes projects, not individual classes. Register interfaces to implementations, choose lifetimes deliberately, keep scope validation on in development and CI, and test that every endpoint resolves.

By default: appsettings.json, then appsettings.{Environment}.json, then user secrets in Development, then environment variables, then command-line arguments. A later source overrides an earlier one for the same key.

Put it under ConnectionStrings in configuration, such as ConnectionStrings:SchoolDb, and read it with builder.Configuration.GetConnectionString("SchoolDb"). Check that it is not null or empty at startup, and keep passwords out of committed files.

A per-user JSON file outside the project folder, linked by the project's UserSecretsId, for local development secrets such as your own connection string. They never reach Git and load only in the Development environment. They are not encrypted and not for servers.

Replace each : with a double underscore: School__CurrentAcademicYear=2027-28 sets School:CurrentAcademicYear. The colon is not valid in environment variable names on every operating system; on the command line, --School:Name=... keeps the colon.

It binds a configuration section to a class, such as SchoolOptions, registered with AddOptions<T>().BindConfiguration("School") and injected as IOptions<T>. It gives typed values, one place for defaults and validation, and classes that do not depend on configuration keys.

IOptions<T> reads the value once for the app's life. IOptionsSnapshot<T> is scoped and reads a fresh value each request, so file changes appear without a restart. IOptionsMonitor<T> is a singleton with the current value and change notifications, for long-lived services.

Bind settings to options classes with validation attributes, and call ValidateDataAnnotations() and ValidateOnStart(). The app then refuses to start with a message naming the setting, so the deployment fails at once and the previous version keeps serving. Add custom Validate rules for checks attributes cannot express.

Treat it as leaked: change the password immediately, check access logs, and only then remove it from the history if needed. Then fix the cause: production secrets come from environment variables or a secret store, local ones from user secrets, and a secret scanner runs on every push.

One build for all environments; safe defaults in appsettings.json; environment differences in environment files or host settings; secrets in a managed secret store, injected at startup with managed identities rather than stored passwords; options classes validated on start; and settings changes reviewed and versioned like code.

OpenAPI is a standard format, in JSON or YAML, that describes an HTTP API: paths, methods, parameters, bodies, responses, and data shapes. It was originally called the Swagger specification; Swagger is now the name of a family of tools around it, such as Swagger UI.

Front-end and mobile developers to learn routes and fields, code generators to create typed clients, testers and test tools to know every status code, API gateways to import routes, and the API team itself as a reference and contract.

Write /// XML comments on actions, with <summary>, <param>, and <response>, and set GenerateDocumentationFile to true in the project file. In .NET 10, the OpenAPI package reads the generated XML file and adds the text to the document.

It declares a status code, and optionally a body type, that an action can return, so the OpenAPI document lists it. Once any response is declared, the success response is no longer inferred: declaring only 404 removed the 200. Declare every response, including the success one.

Register a document transformer in AddOpenApi(options => options.AddDocumentTransformer(...)) and set document.Info.Title. Hide a controller or action with [ApiExplorerSettings(IgnoreApi = true)]; hiding does not protect it, so secure the endpoint separately.

ASP.NET Core's web JSON defaults allow reading numbers from strings, such as "3", so the schema honestly lists both types with a number pattern. Clients normally send numbers; change the JSON number handling if a client generator copes badly with it.

Breaking: removing or renaming a response field, changing a field's type, adding a required request field, removing an endpoint or changing its meaning. Usually safe: adding endpoints or optional fields. Generate the OpenAPI document in the build and compare it with the previous version in every pull request, failing the build on breaking differences.

Only as a deliberate decision. Public APIs often publish them, sometimes behind authentication; internal APIs may expose them only inside the network or not at all. Never expose them by accident, and never rely on hiding endpoints from the document as security.

Treat the document as the contract: generate it from the API in CI, publish each version, generate the mobile client from it, and compare versions to detect breaking changes. Require complete response declarations and descriptions in review, and version the API when a break is necessary.

A pattern for request paths, made of literal segments and parameters in braces, such as api/students/{admissionNumber}. Routing matches the request's path and method against the templates and passes parameter values to the action.

The controller's route is a prefix and the action's template is added to it. [Route("api/students")] with [HttpGet("{admissionNumber}")] gives GET api/students/{admissionNumber}; [HttpGet] alone gives GET api/students.

In the path when it identifies the resource or its place in a hierarchy, such as an admission number or a class and section. In the query string when it is an option on a list: paging, filtering, or sorting, such as ?page=2&pageSize=20.

Rules on a route parameter, such as int, range(1,10), or length(1,2), that decide whether the route matches. When one fails, the route does not match, and the client gets 404 with no explanation, before any action runs. They are for matching, not for validation.

Add parameters with [FromQuery] and default values, such as int page = 1, and put validation attributes on them, such as [Range(1, 100)]. With [ApiController], an invalid value returns 400 ValidationProblemDetails naming the parameter, and the action never runs.

The more specific template wins: a literal over a parameter, a constrained parameter over an unconstrained one, so /api/students/3 chose {id:int} over {admissionNumber}. If two are equally specific, the request fails with an ambiguous match error (500), which must be fixed in the routes.

Add paging with page and pageSize in the query string, a maximum page size, a stable sort ending with the key, and a response that includes the total count. Add filters such as sectionId so clients ask only for what the screen shows, and project to DTOs with only the needed fields.

/api/students for the collection and /api/students/{id} for one student; /api/students/{id}/guardians and /api/students/{id}/fee-invoices for related collections; and /api/fee-invoices/{invoiceNumber} for an invoice by its own key. Keep nesting to two parent levels, use plural lowercase nouns with hyphens, and put filters in the query string.

Keyset (cursor) paging: the client sends the last key it saw, and the query asks for rows after it, such as WHERE (LastName, FirstName, Id) > (@last...), which an index can seek directly. It stays fast at any depth and is stable when rows are added, but it cannot jump to page 400; keep offset paging for screens that need page numbers.

Turning request data into action parameters: route values, query string values, the JSON body, headers, and services. With [ApiController], a complex type such as CreateStudentRequest is read from the body, and simple types from the route or query string.

With data annotation attributes such as [Required], [StringLength(50)], [Range], and [RegularExpression] on its properties or record parameters. With [ApiController], invalid requests get 400 with ValidationProblemDetails before the action runs.

A 201 Created response with the new resource as the body and a Location header built from another action's route, such as the GET for one student. Building the URL from the route keeps it correct when routes change, unlike a hand-written string.

Implement IValidatableObject on the request type and return ValidationResult objects from Validate, naming the fields involved, such as an age rule over DateOfBirth and AdmissionDate. ASP.NET Core calls it only after every attribute has passed.

System.Text.Json reads and writes enums as numbers by default, so a name cannot be converted and the request gets 400. Register JsonStringEnumConverter in the JSON options so enums travel as names, which are clearer and stay stable when enum values are reordered.

Content type (415 if not JSON), then binding (400 for values that cannot be converted, stopping at the first), then attributes (every failing field), then IValidatableObject, then the action. Each step runs only if the previous passed, so clients may need two attempts to see all kinds of errors.

In all three, for different purposes. The request model checks shape and format and gives clients clear 400 errors. The domain enforces business rules for every caller, not just the API. Database constraints are the last guard against any client or bug. Duplicated rules are acceptable when each layer has its own reason.

Accept only an unambiguous format, ISO 8601 (2016-04-12), which DateOnly binds directly, and reject anything else with a 400 that names the field. Fix the app to send ISO dates, and check existing data for swapped day and month values.

One request DTO per operation with declarative rules, cross-field rules in IValidatableObject or a validation library, one error format (ValidationProblemDetails with stable keys and messages), rules visible in the OpenAPI document, and tests for each rule. Keep business rules in the domain and map their errors to the same format.

A standard JSON format for HTTP error responses (RFC 9457), with type, title, status, detail, and instance, plus your own extension fields such as errorNumber. ASP.NET Core can produce it for every error, so clients parse one shape everywhere.

201 Created, with a Location header giving the new resource's address and, usually, the resource in the body. In a controller, CreatedAtAction builds both from another action's route.

Stack traces and messages reveal file paths, library versions, SQL, and internal names that help attackers, and they mean nothing to users. Return a general ProblemDetails with a traceId, and write the full exception to the server log.

400 when the request is malformed or fails field validation. 409 when a valid request conflicts with the current state, such as a duplicate admission number or a record changed by someone else. 422 when a well-formed request breaks a business rule, such as paying more than the balance.

Register AddProblemDetails() and one or more IExceptionHandler classes with AddExceptionHandler<T>(), and put app.UseExceptionHandler() first in the pipeline. Each handler's TryHandleAsync returns true for exceptions it answers; anything unhandled becomes a 500 ProblemDetails.

It fills empty error responses, such as a 404 from a failed route constraint, with a ProblemDetails body. Without it, those responses have no body, so clients see two different error shapes.

Return 4xx codes for client-side and rule failures, such as 422 for amount above balance and 409 for conflicts, so the client knows retrying is pointless, and 5xx only for real server failures, which may be retried. Include a machine-readable errorNumber, and make payments idempotent so a retried request cannot charge twice.

Usually not: repeated try/catch blocks drift apart and hide the action's real work. Let domain exceptions carry a meaning, such as an error number, and translate them in one place: an IExceptionHandler that maps them to status codes and ProblemDetails. Use controller helpers only for outcomes the controller decides itself, such as not found.

One format (ProblemDetails) for every error; a documented catalogue of stable error codes, such as the SMS's 500xx numbers, each with its HTTP status; codes and status listed in the OpenAPI document; human messages that may change and machine codes that never do; a traceId for support; and versioning rules for adding codes without breaking clients.

A fixed outer shape for every response body, such as status, message, and data. A client can then read every endpoint with one piece of code: check status, show message, use data. Without it, each endpoint and each kind of error can have its own shape, and every app needs special parsing for each.

Browsers, proxies, load balancers, monitoring, and retry logic read the HTTP status code, never the JSON body. Answering 200 with "status": "error" hides every failure from them. In the SMS, a missing student is still 404 and a broken rule still 422; the wrapper only changes the body.

A 204 response can never have a body, so it cannot carry the wrapper. With an envelope, every answer has a body, so a successful delete answers 200 with ApiResponse.Ok("Student ADM-2026-10001 was removed.") and no data.

Use two classes: a base ApiResponse with status, message, errorCode, errors, and traceId, and ApiResponse<T> that adds Data. The Fail method returns the base class, so an error object has no Data property at all, and the JSON cannot contain one even by mistake.

Four: exceptions you expect (an IExceptionHandler for SchoolRuleException), every other exception (a last IExceptionHandler that answers 500), automatic validation errors (ApiBehaviorOptions. InvalidModelStateResponseFactory), and empty error responses such as unknown routes or 405 (UseStatusCodePages with a handler). Also set SuppressMapClientErrors, or a bare NotFound() still becomes a ProblemDetails.

The id of the request's trace (Activity.Current.Id in ASP.NET Core). The client gets it in the error response; the server logs the real exception under the same id. Support asks the user for the traceId and finds the exact log entry, without the response ever exposing exception details.

Since .NET 10, the exception handler middleware does not write its own log entry when an IExceptionHandler returns true. The handler answered the client but nobody logged the exception. Fix it by logging inside the handler with ILogger, including the same traceId the response carries, and add a test or check that a crash produces a log entry.

ProblemDetails is a standard: tools, gateways, and generated clients understand it, and success bodies stay plain. An envelope gives one shape for success and error, which many front-end and mobile teams prefer, but it is a house format that every client must learn. Decide by who consumes the API: public or partner APIs lean to standards; one team's own apps often lean to an envelope. Either way, keep real status codes, never leak exception details, and document it in OpenAPI. The SMS chose an envelope for its own apps and keeps the same status codes.

Agree one contract (envelope or ProblemDetails) and publish it as a small shared library with the common Ok and Fail methods, the error handlers, and the validation setup, so services adopt it with a few lines. Define error codes per domain, require a traceId linked to distributed tracing, describe the shapes in each OpenAPI document, and add contract tests that call every endpoint's error paths. Roll it out with API versioning, so existing clients keep the old shape until they move.

Create, read, update, and delete: the basic operations on a record. In a REST API, create is POST, read is GET, update is PUT or PATCH, and delete is DELETE, each on a resource address such as /api/students/{admissionNumber}.

Marking a record as deleted, such as IsDeleted = 1 with a timestamp, instead of removing the row. Students have invoices, payments, attendance, and marks; removing the row would break that history or be refused by foreign keys. A query filter hides soft-deleted rows everywhere.

PUT: 200 with the updated resource, or 204 with no body; 400 for invalid input; 404 when the resource does not exist. DELETE: 204 when removed; 404 when there is nothing to remove, including a second delete of the same resource.

Start from the IQueryable, add a Where only for each parameter that was given, then count, sort, and page. EF Core turns it into one parameterised SQL query; StartsWith becomes LIKE 'text%', which can use an index, and a related-table filter becomes EXISTS.

A class EF Core calls during SaveChanges, such as before the SQL is sent. It can inspect and change tracked entities, for example setting UpdatedAt on every modified entity with audit columns, so no repository or service has to remember to do it.

The check cannot see rows hidden by filters, such as soft-deleted records, and two requests can both pass it at the same moment before either inserts. Only the database sees every row at insert time, so keep a UNIQUE constraint and translate its error (2627 or 2601) into a clear 409.

Soft delete covers normal removals. A permanent erasure request is a separate, audited process: check legal retention rules for fee and academic records, anonymise or remove personal fields while keeping financial and statistical records that must stay, record who approved it, and run it in a transaction.

When clients often change one or two fields of a large resource, when several clients edit different fields of the same record, or when sending every field risks overwriting newer data. Use a clear format, such as JSON Merge Patch or JSON Patch, validate the result after applying it, and combine it with a concurrency check.

Prefix searches on indexed name and number columns for the common cases, always scoped by school and paged with a stable sort. For "contains", spelling mistakes, or several fields at once, use full-text search or a dedicated search engine fed by changes from the database, and keep the API contract the same whichever engine answers.

Master data is reference information that other features depend on, read constantly and changed rarely, such as academic years, classes, sections, and subjects. Transaction data records daily activity, changes constantly, and grows large, such as attendance, marks, and payments.

It tells clients and caches how long they may reuse a response without asking the server again, such as Cache-Control: public,max-age=3600 for one hour. In ASP.NET Core, [ResponseCache(Duration = 3600)] adds it; the server itself stores nothing.

Screens almost always need both. Returning them nested saves the client from making one more request per class, the N+1 problem on the client's side, and EF Core can build the whole tree with one SQL query.

A cached error, such as a 404 for the current academic year, could be shown long after the problem was fixed. ASP.NET Core's exception handling adds Cache-Control: no-cache,no-store to the error responses it writes, so clients and proxies do not keep them.

By how long the data may be stale without harm. Subjects and academic years can be an hour or more; classes with live student counts a few minutes during admissions; attendance or balances not at all. When in doubt, start short and lengthen it after watching how the data changes.

A principal entity, such as Student, is filtered, but a dependent that requires it, such as Enrollment, is not. Queries on the dependent then still return rows whose principal is hidden, such as enrollments of removed students being counted. Give the dependent a matching filter through its navigation, or make the relationship optional.

Merge them: choose one, move every mark, exam paper, and allocation to it in one transaction, then remove the other. Prevent it with unique constraints on both the code and the name, translated into a 409, and restrict master data changes to administrators.

Send Cache-Control with a suitable max-age so clients reuse the answer, and support conditional requests with ETag so clients that do ask get 304 Not Modified. Add server-side caching for the data itself if the database is still busy, and invalidate it when an administrator changes the list.

Separate global reference data, such as a standard subject catalogue, from school-specific data, such as sections and timetables; scope every school-specific row by school; version changes to shared data; cache per school with clear invalidation; and let administrators change only their own school's data.

Each row on one side can relate to many rows on the other, and the other way round. A student has several guardians, and a guardian can have several children at the school. It is stored in a junction table, such as StudentGuardians, with one row per link.

A primary key made of more than one column. In StudentGuardians it is (StudentId, GuardianId): the pair is unique, so a guardian is linked to the same student only once. In EF Core it is declared with HasKey(sg => new { sg.StudentId, sg.GuardianId }).

An empty list with 200: the student exists, and the answer to "which guardians?" is "none". Return 404 only when the parent resource, the student, does not exist, so clients can tell the two cases apart.

As an entity of its own, such as StudentGuardian, with a composite key and two one-to-many relationships, one to each side. EF Core's automatic many-to-many mapping hides the junction table and has no place for columns like Relationship or IsPrimaryContact.

With a filtered unique index on StudentId that includes only rows where IsPrimaryContact = 1. Students may have many guardians, but only one row per student can be in the index, so a second primary contact fails with error 2601.

Leave the controller without a class-level route, or ignore it, and start each action's route with "/", which makes it absolute, such as [HttpGet("/api/students/{admissionNumber}/guardians")] and [HttpGet("/api/guardians/{guardianId:int}/students")].

Fix the code so setting a new primary clears the old one in the same save; clean existing data with a script that keeps one primary per student by an agreed rule and reviews unclear cases; then add a filtered unique index so the data can never break the rule again, whatever code or tool writes to it.

Only what the screens using it need: a staff list needs names, codes, and work emails, not personal phones or dates of birth. Put more sensitive details on single-resource endpoints that fewer roles may call, and check every DTO against who will see it.

Separate the person from their roles: one person record with shared identity and contact details, and role records such as Teacher and Guardian that reference it, each with role-specific data and permissions. Logins attach to the person, and authorization checks roles, so one sign-in can see both the staff and the parent views.

Two requests run at the same time and the result depends on their timing. Two clerks enrolling into one section both read "highest roll number 0" and both save roll number 1; one of them acted on information that was no longer true.

The rules (active student, not already enrolled, capacity, next roll number) are business logic that must hold for every caller, and they need several repository calls in one transaction. A service keeps them in one tested place; the controller only translates HTTP to the service call.

Section full: 409 Conflict, because the request clashes with the section's current state. Student not found: 404. Student not active: 422, a business rule. Each also carries an SMS error number, such as 50034, 50030, and 50032.

Serialize them on something that represents the group: start a transaction and lock its row, such as SELECT ... FROM Sections WITH (UPDLOCK, ROWLOCK), then check and insert, then commit. Requests for the same section wait; other sections are unaffected. Keep a unique constraint as a final guard.

While the group is locked, read the highest existing number and add one, then insert, all in one transaction; back it with a unique constraint on (group, number). Without the lock, two requests compute the same number. A sequence or identity does not fit, because numbering restarts per group.

Rows hidden by the filter still exist and still hold their numbers in the unique constraint. If the highest number is read through the filter, a removed student's number can be handed out again and the insert fails. Read the highest number with IgnoreQueryFilters, while counting capacity with the filter.

Make the timing deterministic: in the test, take the lock with one connection and hold it, start the operation on a second connection, check that it has not finished after a delay, release the lock, and check the operation then completes correctly. Sending two requests by hand rarely overlaps reliably.

When conflicts are likely and the work under the lock is short, such as many clerks enrolling into the same sections in admission week: waiting briefly is better than failing and retrying. Choose optimistic concurrency when conflicts are rare or when a user thinks between reading and saving, where holding a lock would block others for minutes.

Keep the lock scope minimal and the locked work short; move slow work (notifications, documents) after the commit or to a background queue; consider assigning roll numbers in a later batch step so admission only reserves a place; and use a queue per section if demand truly exceeds what one lock can serve.

One request is faster on weak networks, and it can be saved in one transaction, so a register is never half saved. It also lets the API check the register as a whole, such as that every enrolled student is included exactly once.

Sending the same register twice leaves the same result as sending it once: the second request created and updated nothing. On school Wi-Fi, apps retry timed-out requests, so retries must be harmless instead of creating duplicate records.

(Present + Late) divided by all recorded days, times 100, the same rule as Lesson 18's SQL. Kabir had 2 present days out of 3 recorded in July, which is 66.67%.

.NET's built-in abstraction for the current time. The app registers TimeProvider.System; tests pass a provider stopped at a fixed moment. Rules such as "no future dates" then give the same result on every test run, instead of changing as real days pass.

Load the existing rows for the batch's key (section and date) as tracked entities, then for each item update the matching entity if its values differ, or add a new one. One SaveChangesAsync writes the updates and inserts in one transaction, with a unique constraint as the final guard against duplicates.

A day has about 10,000 records. GROUP BY in SQL Server sends back ten rows of counts; loading the records into the API to count them would move all 10,000 rows for the same ten numbers. With an index on the date, the SMS's daily summary took about 120 ms over 600,000 rows.

Duplicate records for the same student and day, usually from retried requests that inserted again. Repair the duplicates, add a unique constraint on (enrollment, date) if missing, and make the save idempotent: one request per register, updating existing records instead of inserting blindly.

Requiring the complete register prevents a forgotten student from looking present or unrecorded, and keeps every day's data comparable. Accepting partial registers suits workflows such as marking late arrivals later; then the API needs explicit "not marked" handling in reports. The SMS requires complete registers and allows corrections by sending the register again.

Index for the main access paths (date; enrollment and date), keep reports aggregated in SQL, pre-compute daily and monthly summaries in a summary table updated after each register, archive or partition old years by date, and serve dashboards from the summaries instead of the raw rows.

Give each paper (one subject's exam for one class) its own address and treat a section's marks sheet as one resource: GET and PUT /api/exam-papers/{paperId}/marks?sectionId=19. Exams and their papers are read with GET /api/exams and /api/exams/{examId}/papers?classId=10, and a report card with GET /api/students/{admissionNumber}/report-cards/{examId}.

Absent and a score of 0 mean different things, and reports must show the difference. The SMS stores IsAbsent = true with null marks; the report card shows "Absent", and a line must have marks or absent, never both (error 50053).

Only when every paper of the exam has been entered. Until then the result is "Incomplete" and the percentage is null, because a missing paper would make the percentage look higher. A complete card is "Pass" only if every paper reached its pass marks.

When a second feature needs exactly the same rule. In the SMS, the register check (every student once, nobody else) was written for attendance; marks sheets needed it too, so it moved to RegisterCheck, and both services call it. Sharing earlier, with only one user, often guesses the wrong shape.

The query only returns what is stored: each paper and the student's mark if there is one. The service decides Pass, Fail, Absent, grades, and the result. Rules change between schools and boards, and in C# they can be unit tested without a database, as the SMS report card tests do.

Catch the SqlException with Number 50001 in the repository and throw the same SchoolRuleException 50001 that the service raises for the same rule. The exception handler then answers 422 with errorCode 50001, whether the C# check or the database caught the problem. Without this, the client gets a 500.

Compare a wrong card with its marks: the usual cause is a percentage calculated from the papers entered so far while some papers were still missing. Fix the rule (no percentage, result "Incomplete", until every paper is entered), add tests for incomplete cards, and give the office a list of missing papers before printing. Reprint the affected cards.

Both. The API checks first and gives a clear message for the user. The database trigger is the final guard for every program that writes marks, such as imports or scripts. Both use error number 50001, and the repository translates the database's error, so clients see one consistent error.

Keep the data query the same and make the rules configurable per school: grade scales as data or as strategies (the IGradeScale idea from Lesson 56), pass marks per paper, and result rules per board. Version the rules so old report cards can be reproduced exactly, cache them per school, and cover each school's rules with tests built from real past results.

Set-based SQL handles many rows in one statement, such as INSERT ... SELECT, instead of one statement per row in a loop. The SMS bills a class of 1,000 students with two inserts and a summary in one transaction and one round trip, in about 0.3 seconds, instead of about 4,000 separate statements.

A sequence is a database object that hands out the next number each time NEXT VALUE FOR is called, safely across many users at once. MAX(number) + 1 can give two requests the same number; a sequence never does. The SMS formats the value as INV-2026-NNNNNN.

A sequence never takes a number back, even when the transaction that used it rolls back or the row is later deleted. In the SMS, test runs used 2,000 numbers, so the next real invoice was INV-2026-002013. Gaps are normal; what must never happen is a duplicate, which the unique constraint on InvoiceNumber prevents.

Let the batch skip what is already done and report it. The SMS insert uses NOT EXISTS to skip students who already have an active invoice; the second run reported 0 created and 1,006 already invoiced. A unique index (one active invoice per enrollment) is the final guard.

Capture the new rows with OUTPUT INSERTED.Id INTO a table variable, then insert the items with INSERT ... SELECT from that table variable joined to the fee lines (a CROSS JOIN, since every invoice gets every line). This works because FeeInvoices has no trigger; on a table with triggers, OUTPUT must use INTO, as here.

Send two statements with the same FROM and WHERE: one returns COUNT and SUM over the whole filter, the other returns one page with ORDER BY and OFFSET/FETCH. Read both with Dapper's QueryMultiple. Totals computed from the page alone would change with the page size.

Repair first: find enrollments with two active invoices and cancel the duplicates, with an audit note. Then fix the design: bill the class in one set-based transaction, so a failure leaves nothing half-done; skip students already billed, so a retry is harmless; and add a filtered unique index so the database refuses a second active invoice.

Each run first takes an application lock for the class (sp_getapplock), so the second clerk waits until the first commits, then its NOT EXISTS check finds every student already billed and creates nothing. If anything slipped past, the filtered unique index would refuse the duplicate and the API would answer 409 (50017). The first SMS version used UPDLOCK, HOLDLOCK on the check instead, and under load two runs could deadlock (error 1205); the application lock removed that.

Run billing as background jobs per school and class, not inside web requests. Each job is set-based, one transaction, and idempotent, so failed jobs can simply be retried. Record each run (who, when, counts) for audit, spread the load over time, give each school its own number series, and notify the office when its run is done. Monitor failures and totals per school.

One request is quicker than six, especially on phones and slow networks, and it is less work for the server. The endpoint is shaped by the screen, not by the tables. The SMS keeps the detailed endpoints for their own screens and adds GET /api/dashboard/summary for the first screen.

It sends several SQL statements in one round trip and returns a reader for their results. You read each result in the same order as the statements; reading out of order maps the wrong rows. The SMS dashboard reads five results this way.

An index that holds every column a query needs, so SQL Server reads only the index and never the table. INCLUDE adds columns to the index without making them part of the key. In the SMS, adding EnrollmentId to the attendance date index cut one day's count from 1,606 pages read to 44.

Run it with SET STATISTICS TIME ON to get the CPU and elapsed time of each statement, and SET STATISTICS IO ON to see how many pages each one reads from each table. The SMS dashboard's attendance statement took 126 ms and read 1,606 pages, which pointed straight at a missing index column.

The query needs another column the index does not hold. In the SMS, the dashboard joins each attendance record to its enrollment, so it needs EnrollmentId as well as Status. Rebuilding the index with INCLUDE (EnrollmentId, Status) and DROP_EXISTING = ON made it cover the query.

It adds the header Cache-Control: public,max-age=60, so browsers and proxies may reuse the response for a minute. It does not cache anything on the server by itself. It suits numbers such as a dashboard that may safely be a little old.

Check that the change was really made: in the SMS, the script's re-run check looked for a column that was already included, so it skipped the rebuild. Then read the index definition from sys.index_columns, and compare pages read with STATISTICS IO before and after. Only trust a fix once the numbers move.

It depends on data that other tests change at the same time: test classes run in parallel. In the SMS, fee totals change while FeeBillingTests creates invoices, so the dashboard test checks only numbers that no other test changes. Alternatives are separate test data, a collection that runs tests one after another, or a database per test run.

Keep one round trip per dashboard and covering indexes for its queries. Cache the result per school for a short time on the server (memory or a distributed cache), refreshed in the background. Pre-compute heavy numbers such as daily attendance into summary tables. Send Cache-Control so clients reuse answers, and watch query times per school in monitoring.

Keep data access behind interfaces such as IStudentRepository, and let one registration method decide the classes. Controllers and services only ask for the interfaces. In the SMS, AddSchoolData changed from the EfCore classes to the Dapper classes, and no controller changed.

Write the condition yourself, such as IsDeleted = 0, in every query that reads the table, including joins and counts. Dapper runs exactly the SQL you write. A test with one removed student catches a forgotten condition.

Dapper runs SQL that the team writes and can read, so queries are exact and easy to review with a database team, and its overhead is very small. EF Core gives change tracking, LINQ, migrations, and less code for simple writes. Many teams use EF Core for writes and Dapper for heavy reads; the SMS chose Dapper for the whole API.

The enum AttendanceStatus was passed as it is, and Dapper sends an enum's number (Late is 2). The Status column holds names, and CK_AttendanceRecords_Status refused the number. Pass Status.ToString(). EF Core did this conversion for us with HasConversion<string>().

Open the connection, start a SqlTransaction, pass the transaction to every Dapper call, and commit at the end. If anything throws, disposing the transaction without committing rolls everything back. In the SMS, the invoice update and the new payment, and the attendance updates and inserts, each use one transaction.

Read the RowVersion with the row. Update with WHERE Id = @Id AND RowVersion = @RowVersion, and read the new value with OUTPUT INSERTED.RowVersion. If no row comes back, someone else saved first: roll back and report a conflict. The SMS reports it as error 50014, just as the EF Core version did.

Use the traceId to find the log entry and its stack trace. In the SMS it pointed to the mapping code, which read payment.FeeInvoice. EF Core's relationship fix-up had always filled that link; Dapper does not. The right fix is in the entity: RecordPayment sets FeeInvoice = this, so the object model is correct whichever tool loads it. Then add a test that checks the link.

Run the same tests against both implementations (the SMS enrollment tests run once per tool, including the lock test). Call the same requests on the old and new builds and diff the responses; the SMS compared 20 GET answers and found no difference. Exercise every write path, then compare timings. Keep the old implementation until all of this passes.

Agree what must be true whatever the tool: repositories behind interfaces, one transaction per business change, concurrency checks, soft-delete rules, parameterised SQL, and integration tests against a real database. Allow EF Core for most CRUD and Dapper where SQL control or speed matters, decided per service and recorded. Provide shared helpers (connection factory, transaction helper, row-to-DTO patterns) and review checklists for the things EF Core did implicitly. Measure before switching for speed.

Code that runs before and after controller actions, inside MVC, for jobs many actions share. Filters can read the action, its attributes, and its bound arguments, and can answer the request themselves. The SMS uses a filter for read-only mode and another for checking date ranges.

Authorization filters, then resource filters, then model binding and validation, then action filters around the action, then exception filters if it throws, then result filters around writing the result. Resource filters also run again at the very end, on the way back.

When the job applies to every request, whatever happens next, including requests for files or unknown routes, which never reach a filter. Use a filter when the job depends on which action runs or on its bound arguments. In the SMS, request timing is middleware; read-only mode and date checks are filters.

It sets context.Result (or, in an async filter, does not call next). That result becomes the response, and the action and the later filters never run. The SMS's ReadOnlyModeFilter sets a 503 ApiResponse this way.

It is a resource filter, which runs before model binding and validation. In the SMS read-only mode, an empty admission request got 503 because the filter refused it before validation ever read the body. An action filter would run after validation, and the client would get 400 first.

Attribute filters are created by .NET, not by dependency injection, so their constructors cannot ask for services. Use [ServiceFilter(typeof(MyFilter))] (the filter is registered and taken from DI) or [TypeFilter(typeof(MyFilter))] (created with services filled in), or register the filter globally with options.Filters.Add of the type, as the SMS does for ReadOnlyModeFilter.

A global resource filter that refuses every non-GET request with 503 and Retry-After while a setting is on, with an attribute to exempt actions such as sign-in. Read the setting with IOptionsMonitor, so the office can switch it without a restart or deployment. Keep the message clear, and test both modes.

The filter reads the setting through IOptions, which binds the value once. IOptionsMonitor.CurrentValue (or IOptionsSnapshot per request) sees reloaded configuration. Also check the file is the one the app actually reads (the content root) and that reloading is on, which is the default for appsettings.json.

Clients send an Idempotency-Key header with each payment. A resource filter (or middleware) stores the key with the response in a shared store (database or distributed cache) for a limited time, and when the same key arrives again it replays the stored response instead of running the action. Store keys per user, handle two identical requests arriving at once with a unique constraint or lock, and reject a reused key with a different body.

Levels rank how important an entry is: Trace, Debug, Information, Warning, Error, Critical. Warning is for something unusual that was handled, such as a school rule refusing a request or a slow request; Error is for a failure the user saw, such as an unhandled exception. Settings choose the minimum level per category.

Writing log entries from a message template with named holes, such as "Payment {ReceiptNumber} recorded", so each value is kept as a separate property. Log systems can then search and count by property (ReceiptNumber = RCP-2026-000069) instead of parsing text.

Passwords, access tokens, signing keys, and personal data such as names, birthdays, phone numbers, and addresses, and whole request or response bodies that may contain them. Logs are read by more people and kept in more places than the database. The SMS logs ids only.

String interpolation turns the value into plain text, so it cannot be searched as a property, and the string is built even when the level is turned off. Use a message template, LogInformation("Payment {ReceiptNumber}", receipt), or a [LoggerMessage] method.

The compiler generates the body of a static partial logging method: fast (no boxing, the template parsed once), typed (a missing argument is a build error), with a fixed event id and level. The SMS keeps every deliberate message in one SchoolLog class this way.

Open a logging scope after authentication, for example in a small middleware: logger.BeginScope("UserId:{UserId}", userId). Every entry written inside the scope carries UserId, and the JSON formatter stores it as a property. Code that runs outside the scope, such as the exception handler, must add the user to its own message.

Search the logs for the trace id. In ASP.NET Core it is the middle part of the response's traceId (00-<TraceId>-<SpanId>-00), and every log entry of that request carries it as a scope. The matching entries show the request path, the user, the rule or exception, and the timing.

Stop the leak first: remove request-body logging and any log line that includes personal data, and deploy. Then treat the stored logs as an incident: restrict access, delete or redact them according to policy, and ask affected users to change passwords. Prevent it returning with deliberate log messages that take ids only, and tests that check sensitive text never appears in logs.

Structured JSON logs with fixed event ids, sent to a central store; distributed traces with the same trace ids across services (OpenTelemetry); and metrics such as request rates, error rates, and response times per endpoint and school. Add the school and user ids as scopes, alert on symptoms (error rate, slow requests), keep personal data out, and set retention and access rules for each kind of data.

A cache keeps a copy of an answer close by so the next request does not ask the source again. Cache data that is read far more often than it changes and that may safely be a little old, such as the current academic year or the list of subjects. Never cache data that must be exact, such as a fee balance.

[ResponseCache] sends a Cache-Control header so each browser or proxy may keep its own copy; the server cannot take it back early. A server-side cache such as HybridCache keeps the copy in the API's memory, serves every client from it, and can remove entries when data changes. They work well together.

It names everything the answer depends on, and nothing else, so two different questions never share an answer. The SMS dashboard key is dashboard:{yearId}:{date}; leaving out the date would return one day's numbers for another. Per-user answers need the user in the key, or should not be cached.

It returns the cached value for a key, or runs the given function once, stores its result, and returns it. Stampede protection means that when many requests ask for the same missing key at once, the function runs only once and all of them share the result, instead of all hitting the database together.

Write a decorator: a class that implements the same interface, holds the real repository, answers reads from the cache, and passes everything else through. Register it in place of the real one. In the SMS, CachedMasterDataRepository wraps the Dapper repository, and no controller or service changed.

Give related entries a tag when you store them, and remove the tag in the same code path that changes the data. In the SMS, every subject entry carries the tag "subjects", and AddSubjectAsync calls RemoveByTagAsync("subjects"), so the new subject appears at once instead of after an hour.

The balance was cached, so the app showed the copy from before the payment. Money and other exact, per-person data should not be cached; if a cache is truly needed, remove the student's entry in the payment code path and keep expiry very short. Review every cached item with the question: what harm does the old version cause?

Only that server removes its cached subjects; the other two keep their copies until they expire, so users may see different lists for up to an hour. Options: shorter expiry, a shared distributed cache (such as Redis as HybridCache's second level), or broadcasting removals to every server.

Put the school in every key (and tag by school), so no school ever sees another's data. Use a two-level cache: memory on each server for speed, plus a shared distributed cache for consistency and warm restarts. Cache master data and computed dashboards with expiry matched to how often each changes, remove tags in the code that changes data, protect against stampedes, and watch hit rates and memory per school.

A change that makes existing clients fail or misread data: removing or renaming a response field, changing a field's type or meaning, making an optional request field required, or changing a status code. Adding a field, an endpoint, or an optional request field is not breaking, because old clients ignore it.

In the URL path (/api/v2/students/...), in a header (X-Api-Version: 2), or in the query string (?api-version=2.0). URL versions are visible and easy to test and cache; headers keep URLs clean but are invisible in links and logs. The SMS uses the URL segment, and the key is to use one style everywhere.

Make unversioned requests mean version 1. In Asp.Versioning, set DefaultApiVersion to 1.0 and AssumeDefaultVersionWhenUnspecified to true. In the SMS, /api/students/... still answers exactly as before, and /api/v1/... is the same endpoint with the version named.

Add Asp.Versioning.Mvc, mark the existing controller [ApiVersion("1.0")], and add a new controller marked [ApiVersion("2.0")] with a route such as api/v{version:apiVersion}/students. Give both the same [ControllerName] so the package groups them and reports both versions.

Asp.Versioning groups versions by controller name. A StudentsController (1.0) and a StudentsV2Controller (2.0) look like two different APIs, so each reports only its own version. [ControllerName("Students")] on the version 2 class makes both report 1.0, 2.0.

Only for breaking changes. If the change can be additive, such as adding firstName and lastName next to fullName, do that: old clients keep working and there is one version to maintain. Add a version when a field must be removed, renamed, or change meaning, or a response must be reshaped.

Restore the old field at once (or serve the old shape again) so installed apps work. Move the rename into a new version that new app releases use. Add a rule and a review step: no field is removed or renamed without a new version and a deprecation date, and add tests that pin the version 1 response shape.

Mark it deprecated (so responses list it in api-deprecated-versions) and publish a date; log which version each request uses and contact the clients still on it; after the date, remove it and answer its routes with a clear error. For a school, one full academic year is a sensible notice period.

One style for all APIs, semantic rules for what counts as breaking, and a preference for additive changes. Breaking changes get a new major version with a published support period (for example, at least 12 months), deprecation headers, per-version documentation, and usage dashboards per client. Contract tests guard each supported version, and an API gateway can route versions to different services if needed.

A hosted service is a class the app starts when it starts and stops when it stops (IHostedService, registered with AddHostedService). BackgroundService is a base class for one: you override ExecuteAsync, which runs in the background for the life of the app, and its stoppingToken is cancelled at shutdown.

Work the user's next step does not depend on, especially slow work or work that calls another service: sending messages, emails, and reports. In the SMS, saving a payment stays in the request; the receipt message is queued. Moving it also stops a slow or failing provider from failing the payment itself.

Register a queue as a singleton, for example a bounded Channel of messages. The controller writes a message and returns at once; a BackgroundService reads the channel with ReadAllAsync and processes each message. Bounded with FullMode.Wait means a flood of work waits for room instead of using up memory.

Not through the constructor: a hosted service is a singleton, and the app refuses to start with "Cannot consume scoped service ... from singleton IHostedService". Inject IServiceScopeFactory, create a scope for each piece of work (CreateAsyncScope), and resolve the repository from that scope; disposing the scope cleans it up.

Since .NET 6 the default BackgroundServiceExceptionBehavior is StopHost: the whole app shuts down, every endpoint included. Catch exceptions inside the loop (except cancellation at shutdown), log them, and carry on with the next message or the next scheduled run.

A BackgroundService loop: get the time from TimeProvider, work out the next 18:00, await Task.Delay(next - now, timeProvider, stoppingToken), run, repeat. Because the clock is injected, a test uses FakeTimeProvider: set it to 17:59, start the job, Advance one minute, and check the job ran, without waiting.

Let the database decide. Record each reminder in a table with a unique key on (invoice, date) before sending, and send only if the insert succeeded; the second server gets a duplicate-key error and skips that invoice. Alternatives are a distributed lock (such as sp_getapplock) or a scheduler that runs each job on one server.

Messages waiting in memory are lost when the app stops or crashes. With an outbox, the message is saved in a table in the same transaction as the business change (such as the payment); a worker reads unsent rows, sends them, and marks them sent. Nothing is lost on restart, but sending is at least once, so receivers must handle duplicates.

Separate the API from the workers: the API writes messages to an outbox table or a durable broker (Azure Service Bus, RabbitMQ), and a scalable pool of worker services sends them. Add retries with backoff, a dead-letter queue for messages that keep failing, idempotency keys so retries never double-send, rate limits per provider, and dashboards for queue length and failures. Schedules run in one place (Hangfire, Quartz.NET, or a cloud scheduler) so each job runs once.

When it has accepted the work but not finished it, because the work continues in the background. 200 says "done, here is the result"; 202 says "accepted, it will be done". In the SMS, POST /api/fee-reminders answers 202 with how many reminders were queued; the worker sends them afterwards.

An address, such as /health/ready, where the API reports whether it is working. Load balancers call it every few seconds to decide which servers get traffic, container platforms use it to restart or pause instances, and monitoring tools use it to alert the team.

Liveness asks "is the process running?" and failing it usually means restart the process. Readiness asks "can it do its work now?" (database reachable, workers running) and failing it means send no traffic until it recovers. A database problem belongs in readiness, because restarting the API does not fix the database.

Healthy: everything works (200). Degraded: it works but needs attention, such as a growing queue (200, so traffic keeps flowing). Unhealthy: it cannot do its job, such as the database being unreachable (503).

Implement IHealthCheck: open a connection, run SELECT 1, return HealthCheckResult.Healthy; catch exceptions (except cancellation) and return Unhealthy with the exception, so it is logged. Register it with AddHealthChecks().AddCheck("database", tags: ["ready"], timeout: ...) and map it with MapHealthChecks.

A fallback authorization policy requires a token on every endpoint, and the load balancer sends none. Mark the health endpoints AllowAnonymous, keep their body free of secrets and exception details, and also exclude them from rate limiting, because a 429 looks just as dead.

BackgroundService.ExecuteTask is the running ExecuteAsync. Hosted services are singletons, so the check can ask for IEnumerable of IHostedService, find the worker, and report Unhealthy if ExecuteTask is completed while the app is running. Queue length and the last run's result can add Degraded warnings.

The database check was in the liveness probe, so the platform restarted every instance, and they were still starting when the database returned. Keep liveness trivial (the process answers) and put the database in readiness, which only removes instances from traffic. Add timeouts so a hanging check fails fast.

No. Include what the instance itself needs and can be fixed per instance, such as its database connection. A shared external service (an SMS provider, a payment gateway) failing would mark every instance unready at once and turn a partial problem into a full outage. Monitor those separately and degrade gracefully.

Per instance: a trivial liveness probe and a readiness probe with fast, time-limited checks of its own dependencies, answering only a status publicly and details on an internal address. Per service: synthetic checks from outside that exercise real flows, dashboards of error rates and latency, and alerts with clear owners. Health results can also be pushed (IHealthCheckPublisher) to the monitoring system, and shared dependencies are watched centrally rather than in every probe.

Unit tests check one class with fakes instead of a database, and run in milliseconds. Integration tests check code together with a real dependency, such as SQL that runs against SchoolDb. API tests run the whole application in memory (WebApplicationFactory) and send real HTTP requests through routing, security, validation, and the database.

A guideline for the shape of a test suite: many fast unit tests at the bottom, fewer integration tests in the middle, and fewer still slow end-to-end or API tests at the top. Fast tests give quick feedback and pinpoint failures; the slower ones prove the parts work together.

The share of code lines (or branches) that ran during the tests. It does not say the lines were checked: a test without asserts still covers code. Use it to find code no test touches, not as proof of quality.

Find every controller type in the API assembly and create each one in a DI scope with ActivatorUtilities.CreateInstance, the way MVC does. Collect the exceptions and fail with their messages. It catches the mistake even though the app starts normally, because controllers are only created when a request reaches them.

Read the endpoints from EndpointDataSource in a WebApplicationFactory, select those with IAllowAnonymous metadata, and compare them with an approved list in the test. With a fallback policy that requires sign-in, every other endpoint is locked; a newly opened one fails the test until someone approves it.

The number of lines counted. Excluding CompilerGeneratedAttribute, for example, removes every async method's generated state machine, so most async code disappears from the report. Exclude only truly generated files (such as obj/), and treat any change in coverage without a change in tests as suspicious.

The test produces output (here, the sorted list of routes with versions) and compares it with an approved file in source control. Any difference fails the test and writes a received file; if the change is intended, the developer replaces the approved file and the change appears in code review. It stops routes being removed or renamed by accident, which would break installed clients.

Each test creates its own data and removes it in finally, or works on data no other test changes; tests that touch the same rows share an xUnit collection so they never run at the same time. Avoid depending on today's date (inject TimeProvider) and on counts that other tests change. Alternatives are a transaction rolled back per test, a tool that resets tables (such as Respawn), or a fresh database container per run.

A pyramid with clear ownership: fast unit tests on every save, integration and API tests in CI on every pull request against containerised dependencies, and contract tests (approved routes, OpenAPI diffs, consumer contracts) to protect clients. Add whole-API safety nets for security and DI, coverage reports per pull request to spot untested changes, flaky-test tracking with quarantine, time budgets for the suite, and smoke tests after each deployment.

An origin is the scheme, host, and port of an address, such as http://localhost:5173. Two addresses have the same origin only when all three match; the path does not count. A page on port 5173 calling an API on port 5080 is a cross-origin call.

Cross-Origin Resource Sharing. Browsers stop a page from reading answers from another origin unless the server allows it with the Access-Control-Allow-Origin header. The browser enforces it; curl, Postman, and other servers ignore it, so the API must still check tokens and permissions itself.

Open the browser's console and Network tab. A CORS refusal is explained in the console, for example "No 'Access-Control-Allow-Origin' header is present". The page's code only gets "Failed to fetch", on purpose, so the console is where the reason is.

An OPTIONS request the browser sends before the real one, carrying Origin, Access-Control-Request-Method, and Access-Control-Request-Headers. It is sent for requests that are not simple: an Authorization header, a JSON body, or methods like PUT and DELETE. Without permission in the answer, the real request is never sent.

Before UseAuthentication and UseAuthorization. The preflight carries no token, so if authorization runs first, the preflight gets 401 with no CORS headers and every browser call fails. In the SMS, moving it after UseAuthorization turned the preflight's 204 into a 401.

No. ASP.NET Core answers the preflight with 204 either way. What matters is the missing Access-Control-Allow-Origin header: without it the browser refuses, and the real request is never sent. Test for the header, not the status code.

One named policy with exact origins read from configuration: empty by default, the local front end in Development, the real websites per server. Validate the origins at startup (no path, no trailing slash), allow only the methods and headers the front ends use, expose only the response headers they must read, set a preflight max age, and cover it with tests that send preflights from allowed and unknown origins.

It lets any website read the API's answers inside your users' browsers, which matters most when the browser sends credentials automatically, such as cookies; ASP.NET Core refuses to combine it with AllowCredentials. It is acceptable for truly public, read-only data with no credentials, such as a public book catalogue, in a separate policy on those endpoints only.

Avoid cross-origin calls where you can: serve the front end and API under one origin through a gateway or reverse proxy, or use a backend-for-frontend. Where CORS is needed, manage the allowed origins centrally per environment, validate them in CI and at startup, keep policies identical across environments except for origins, and test preflights in the pipeline. Never treat CORS as authentication; tokens and authorization stay on every API.

Each new HttpClient opens new network connections, and closed ones linger for a while, so a busy server can run out of them. One HttpClient kept forever has the opposite problem: it never notices a changed DNS address. IHttpClientFactory reuses connections and renews them every two minutes by default.

Retry errors that can pass: 5xx answers, 408, 429, timeouts, and broken connections. Do not retry 400, 401, 403, 404, 409, or 422: the request itself is wrong and will fail the same way again.

A class that takes an HttpClient in its constructor and knows one service's API, registered with AddHttpClient<TInterface, TImplementation>(). The factory creates its HttpClient with the address, time limits, and retries set in one place, and the rest of the app only sees the interface.

Backoff makes each wait longer than the last (about 1, 2, 4 seconds), so a struggling service gets time to recover. Jitter adds a random part to each wait, so many clients that failed together do not all retry at the same moment and overload the service again.

A unique id for one operation, sent in a header such as Idempotency-Key, the same on every attempt. If the service already handled that key, it returns the first result instead of doing the work again. You need it whenever you retry a request that changes something, such as a POST that sends a text or takes a payment, because a lost answer would otherwise cause a duplicate.

Closed: calls go through and failures are counted. Open: after too many failures, every call fails at once without touching the service, for a break period. Half-open: after the break, one trial call goes through; success closes the circuit, failure opens it again.

A typed client from IHttpClientFactory behind an interface; a time limit per attempt and a total limit; retries only for transient errors, with backoff and jitter; an idempotency key on every changing request; a circuit breaker; logs and metrics for retries and circuit events. Work that must not be lost goes into an outbox table first and is sent by a background job that can retry later. Tests replace the network with a scripted handler.

Retries cover seconds, not hours. Store each message durably before sending, in an outbox table with a status, in the same transaction as the business change. A background job sends pending rows, marks them sent, and retries failures later with growing delays, keeping the idempotency key, and alerts after too many failures.

Give every call a time budget shorter than the caller's own, and pass deadlines along. Retry only at one layer, so retries do not multiply through the chain, and cap them with retry budgets. Use circuit breakers and bulkheads (separate limits per dependency), idempotency keys for changing calls, and asynchronous messaging with durable queues where an immediate answer is not needed. Keep shared dependencies out of readiness checks, and watch retry and circuit metrics on dashboards.

The client sends a multipart form, and the file part arrives as an IFormFile parameter whose name matches the form field. IFormFile gives the length, the claimed file name and content type, and OpenReadStream() to read the bytes.

Only what actually arrives: its size, and its content after you check it. The file name, extension, and content type are chosen by the user's computer, so never use the name to save the file, and check the content itself, for example the header row of a CSV or the first bytes of a picture.

Return the bytes with the right content type and a Content-Disposition: attachment; filename=... header. In ASP.NET Core, File(...), PhysicalFile(...), or Results.Stream(..., contentType, fileDownloadName) set it from the file name you pass.

[RequestSizeLimit] on the action (or Kestrel's MaxRequestBodySize) stops reading beyond the limit, and form options limit multipart bodies. In an MVC action, the failed form read becomes a 400 "Request body too large" before the action runs. Check IFormFile.Length in code as well, since a test server may not enforce the limit.

For a positional record, ASP.NET Core requires validation attributes on the constructor parameters, and throws if they are on the properties. Validator reads only properties, so it does not see them. Outside MVC you must read the parameters' attributes yourself, as the SMS's RecordValidator does, or validate differently.

Read rows one at a time (for example Dapper's QueryUnbufferedAsync as an IAsyncEnumerable) and write each to the response stream as it arrives, for example inside Results.Stream. The response goes out chunked, memory stays flat, and the client starts receiving data at once.

Check the file (size, header), then every row with the same rules as the single-record endpoint, collecting errors by row. Bulk-copy valid rows into a staging table, check them against existing data, and apply one MERGE in a single transaction; any problem rolls everything back and returns every error. Matching on a natural key makes a repeated upload change nothing. Return counts of added, updated, and unchanged rows.

Uploads: huge files (limit size), path traversal through file names (never use them; generate names), lying types (check content and signatures), malware (scan files that are stored or shared), and public folders (store outside them and serve through an endpoint that checks permissions). Exports: CSV injection, where a value starting with =, +, -, or @ runs as a formula; neutralise such values. Both need authorization.

Do not stream large files through the API servers. The API authorises the upload and returns a short-lived signed URL to object storage; the client uploads directly, in resumable chunks. A storage event triggers background processing: virus scan, type check by content, thumbnails or conversion, then the metadata row is marked ready. Downloads use signed URLs or a CDN. Set size and type limits, quotas per tenant, retention rules, and encryption at rest.