ASP.NET Core Web API interview questions covering routing, API versioning, OpenAPI, Swagger and API documentation.
Open a question for the full answer, code and interview guidance.
Routing matches an incoming HTTP request to an API endpoint. ASP.NET Core considers route templates, HTTP methods, route values, constraints, and endpoint metadata when selecting the action that should handle a request.
A route template describes the URL pattern accepted by a controller or action. Templates can contain literal segments, parameters, optional values, defaults, and constraints.
Route constraints restrict which URL values can match a route parameter. Common constraints include int, guid, bool, datetime, length, min, and max.
Route tokens are placeholders replaced using controller or action metadata when routes are built. The controller token commonly removes the Controller suffix from the class name.
A catch-all route parameter captures the remaining path segments into one route value. It is useful for endpoints that intentionally accept path-like data.
Nested routes can express a meaningful parent-child relationship, such as a customer's orders. They are useful when the child is naturally scoped by the parent.
URL generation creates a URI from route information rather than manually concatenating strings. This is useful for Location headers and links because generated URLs remain aligned with configured routing.
LinkGenerator is an ASP.NET Core service for generating endpoint URLs outside the convenience methods available on controllers. It can generate paths or absolute URIs using endpoint names, action information, or route values.
API versioning allows an API to evolve while maintaining defined contracts for clients that still depend on older behavior. Different versions may expose different request models, response models, routes, or semantics.
Common strategies include putting the version in the URL path, query string, custom header, or media type. Each approach has trade-offs involving visibility, caching, client ergonomics, and routing.
A new version is appropriate when a public contract must change incompatibly and existing clients cannot safely consume the new behavior. Examples can include removing or renaming required fields, changing meanings, or restructuring resources incompatibly.
Backward compatibility means existing clients can continue operating correctly after the API is updated. Preserving field meanings, accepted inputs, status-code behavior, and documented endpoint semantics helps avoid breaking consumers.
Deprecation communicates that an API version or feature remains available temporarily but should no longer be used for new integrations and is planned for retirement.
OpenAPI is a machine-readable specification for describing HTTP APIs. It can describe paths, operations, parameters, request bodies, response schemas, authentication requirements, and other contract metadata.
OpenAPI is the specification, while Swagger commonly refers to a family of tools built around API descriptions, such as interactive Swagger UI. In ASP.NET Core, developers often generate an OpenAPI document and expose an interactive UI for development or documentation.
Register the required OpenAPI/Swagger services during startup and expose the generated document and UI through middleware. The exact package and APIs depend on the application's .NET version and chosen OpenAPI tooling.
ProducesResponseType declares expected HTTP response codes and, optionally, response body types for an action. OpenAPI tooling can use this metadata to describe success and failure responses more accurately.
The OpenAPI document can define a security scheme such as HTTP bearer authentication and apply security requirements to protected operations. Interactive documentation tools can then allow a developer to supply a token when testing authorized endpoints.
XML documentation comments can describe controllers, endpoints, parameters, return values, and DTO properties in source code. OpenAPI tooling can include the generated XML file to enrich API documentation.
An operation ID is a unique identifier for an API operation within an OpenAPI document. Client generators may use operation IDs to create method names.
Examples show clients realistic request and response payloads in addition to schemas. They can clarify formatting, optional fields, enums, error contracts, and typical values.
It depends on the API's exposure model and organizational requirements. Public APIs may intentionally publish interactive documentation, while private or security-sensitive systems may disable it, restrict it to authenticated users, or expose documentation through a separate developer portal.
Identify the affected public contract, introduce a compatible path or new API version, document the change, and provide consumers enough time and guidance to migrate. Monitor usage where possible before retiring the old contract.
In code-first development, the application code and metadata are used to generate the API description. In contract-first development, an OpenAPI or similar contract is designed first and implementation is built to satisfy it.
Use predictable resource-oriented routes, appropriate constraints, and URL generation instead of manually constructing links. Keep public routes stable and avoid unnecessary deep nesting or implementation-oriented action names.