ASP.NET Core Web API interview questions covering REST fundamentals, controllers, HTTP methods and status codes.
Open a question for the full answer, code and interview guidance.
ASP.NET Core Web API is a framework for building HTTP services on .NET. It is commonly used to expose application data and operations to web applications, mobile apps, desktop clients, other services, and third-party integrations.
REST stands for Representational State Transfer. It is an architectural style for networked systems in which resources are identified by URIs and manipulated through standard HTTP semantics.
A resource is a concept or entity exposed by an API, such as a product, customer, order, or invoice. A resource is normally identified by a URI and represented in a format such as JSON.
An MVC controller commonly returns Razor views as well as other result types and normally derives from Controller. An API controller primarily returns data and HTTP results and commonly derives from ControllerBase.
ControllerBase is the base class commonly used for API controllers that do not need Razor view support. It provides API-focused helpers and properties such as Ok, NotFound, BadRequest, CreatedAtAction, User, Request, and ModelState.
The ApiController attribute enables API-specific conventions and behaviors. Important features include automatic HTTP 400 responses for invalid model state, binding-source inference, attribute-routing requirements, and improved API error behavior.
Attribute routing places route templates directly on controllers and actions. It makes the HTTP contract explicit and works well for APIs because each endpoint can clearly declare its URI pattern, HTTP method, and route constraints.
Route parameters normally identify a particular resource or a hierarchical part of the resource path. Query-string parameters commonly represent optional filtering, searching, sorting, pagination, or other modifiers to a collection request.
GET retrieves a resource or collection. POST commonly creates a new resource or submits a command. PUT commonly replaces or fully updates a resource at a known URI. PATCH applies a partial update. DELETE removes a resource.
GET is intended to retrieve a representation without requesting a state change and is considered safe. POST submits data for processing and is commonly used to create resources or execute operations that change server state.
PUT generally represents replacement or a complete update of the target resource representation, while PATCH represents a partial modification. The exact contract must be documented because APIs sometimes use PUT with update DTOs that do not literally contain every stored field.
An operation is idempotent when repeating the same request has the same intended effect on server state as performing it once. GET, PUT, and DELETE are defined with idempotent semantics, while POST is not inherently idempotent.
A safe HTTP method is intended only for retrieval and should not request a state change in application data. GET, HEAD, and OPTIONS are examples of safe methods.
HTTP status codes communicate the high-level outcome of a request using a standardized protocol contract. Clients can use the status code before interpreting the response body.
200 OK indicates that the request succeeded and the response contains a representation or result. It is commonly used for successful GET requests and for other successful operations that intentionally return a response body.
201 Created is appropriate when a request successfully creates a new resource. The response should normally identify the URI of the newly created resource, commonly through the Location header.
204 No Content indicates that the request succeeded and there is intentionally no response body. It is commonly used after successful update or delete operations when the client does not need a representation returned.
400 Bad Request indicates that the server cannot process the request because the request itself is invalid, such as malformed syntax or invalid API input. With ApiController, validation failures commonly produce an automatic 400 response.
401 Unauthorized means the request lacks valid authentication credentials for the protected resource. Despite its historical name, it is primarily an authentication response.
404 Not Found indicates that the requested resource or route cannot be found. For a resource endpoint, return 404 when the identifier is valid in form but no matching accessible resource exists.
409 Conflict indicates that the request cannot be completed because it conflicts with the current state of the target resource or system. Examples include certain duplicate-key situations, concurrency conflicts, or state transitions that collide with existing state.
DTO stands for Data Transfer Object. A DTO defines the data contract exchanged between an API and its clients, such as CreateProductRequest, UpdateProductRequest, or ProductResponse.
Persistence entities are designed around database and domain concerns, while API contracts are designed for clients. Returning entities directly can expose internal fields, create serialization problems with navigation properties, encourage overposting, and tightly couple the API to the database model.
Content negotiation is the process of selecting an appropriate representation format for a response based on the endpoint capabilities and request information such as the Accept header. JSON is the normal default format for modern ASP.NET Core APIs.
Model endpoints around clear resources and use HTTP methods and status codes consistently. Use attribute routing, API controllers, request and response DTOs, server-side validation, asynchronous I/O, cancellation tokens, and appropriate authentication and authorization.