The short answer: web API interviews test whether you can design, secure and run HTTP APIs that other teams rely on. Expect REST principles, HTTP methods and their semantics (especially safe and idempotent methods), status codes, versioning and pagination, authentication and authorization, API security (the OWASP API Security Top 10), framework questions (often ASP.NET Core Web API, Node or Spring), and scenario questions for experienced developers, such as handling retries without double-charging a customer.
REST and HTTP fundamentals
“What is a REST API?”
An architectural style for APIs over HTTP: resources identified by URLs (/orders/42), manipulated with standard HTTP methods, with stateless requests (each request carries what the server needs, such as an auth token) and standard representations such as JSON.
“What’s the difference between safe and idempotent methods?”
RFC 9110, the HTTP semantics standard, defines a safe method as essentially read-only: the client doesn’t request or expect any state change on the server. An idempotent method is one where several identical requests have the same intended effect as a single one. GET, HEAD and OPTIONS are safe; PUT and DELETE are idempotent but not safe; POST is neither, and PATCH isn’t guaranteed to be idempotent.
“PUT vs PATCH vs POST?”
- POST creates a resource or triggers processing (
POST /orders). - PUT replaces a resource at a known URL (
PUT /orders/42with the full order). - PATCH applies a partial update (change only the shipping address).
“Which status codes do you use?”
| Code | When |
|---|---|
| 200 OK / 201 Created / 204 No Content | Success; 201 for a created resource (with its location), 204 when there’s no body |
| 400 Bad Request | Malformed request or failed validation |
| 401 Unauthorized | The client isn’t authenticated. MDN notes it semantically means “unauthenticated” |
| 403 Forbidden | Authenticated, but not allowed; the server knows who the client is |
| 404 Not Found | The resource doesn’t exist |
| 409 Conflict | The request conflicts with the current state, such as an edit conflict |
| 422 Unprocessable Content | Well-formed but semantically invalid (used by some APIs for validation) |
| 429 Too Many Requests | Rate limit exceeded |
| 500 / 503 | Server error / temporarily unavailable |
API design questions
- “How do you version an API?” In the URL (
/v1/), a header, or a media type. URL versioning is the most visible and common. Above all, avoid breaking changes: add optional fields, don’t remove or rename existing ones without a new version and a deprecation period. - “How do you paginate?” Offset and limit for simple cases; cursor-based pagination for large or frequently changing data, because it’s stable and efficient. Return the next cursor in the response.
- “How do you design error responses?” A consistent structure with a machine-readable code, a human-readable message, field-level details for validation errors, and a correlation ID for support. Many APIs use the Problem Details format (RFC 9457).
- “REST, GraphQL or gRPC?” REST for broad compatibility and caching; GraphQL when clients need flexible queries across many resources; gRPC for fast, typed service-to-service calls.
Security questions
“How do you secure a web API?”
HTTPS everywhere; authentication (commonly OAuth 2.0 with JWT access tokens, or API keys for server-to-server use); authorization checked on every request, including access to each specific object; input validation; rate limiting; and logging and monitoring.
“What is the OWASP API Security Top 10?”
OWASP’s 2023 list of the most critical API risks: API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Object Property Level Authorization, API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization, API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery, API8 Security Misconfiguration, API9 Improper Inventory Management, and API10 Unsafe Consumption of APIs. Be ready to explain API1: a user changes /orders/42 to /orders/43 and sees someone else’s order because the API checked authentication but not ownership.
“How do JWTs work, and what are the pitfalls?”
A signed token carrying claims (user ID, scopes, expiry) that the API verifies without a database lookup. Pitfalls: long lifetimes, storing sensitive data in the payload (it’s encoded, not encrypted), not validating signature, issuer, audience and expiry, and difficulty revoking tokens before they expire.
ASP.NET Core Web API questions
- “Controllers or minimal APIs?” Microsoft’s documentation says ASP.NET Core supports web APIs with either controllers or minimal APIs. Controllers suit larger APIs with filters and conventions; minimal APIs are concise for smaller services.
- “Why derive from
ControllerBaseinstead ofController?” Microsoft’s guidance: web API controllers should typically derive fromControllerBase;Controlleradds view support for web pages. - “What does
[ApiController]do?” Enables API-specific behaviors such as attribute routing requirements, automatic 400 responses when model validation fails, and binding-source inference. - “How do you handle errors globally?” Exception-handling middleware returning consistent Problem Details responses, rather than try/catch in every action.
See our .NET Core and ASP.NET interview questions for middleware and dependency injection.
Performance and reliability questions
- “How do you make an API fast?” Efficient queries and indexes, pagination, caching (HTTP caching headers with ETags, or a server-side cache), compression, and async I/O.
- “How do you protect an API from overload?” Rate limiting per client, timeouts, circuit breakers for downstream calls, and queueing slow work.
- “How do you observe an API in production?” Structured logs with correlation IDs, metrics (request rate, error rate, latency percentiles), traces across services, and alerts on user-facing symptoms.
Scenario questions for experienced developers
- “A client’s request timed out. They retry. How do you avoid charging the customer twice?” Make the operation idempotent with an idempotency key: the client sends a unique key with the POST, the server stores the result for that key and returns the same response on retries.
- “You need to change a field’s type in a public API.” Add a new field alongside the old one, document the deprecation, monitor usage, and remove the old field only in a new version after clients have moved.
- “An endpoint is slow under load.” Measure first (traces and query plans), then look for N+1 queries, missing indexes, large payloads and synchronous calls to slow dependencies.
- “How would you design a webhook system?” Signed payloads, retries with exponential backoff, idempotent consumers, and a way for clients to replay missed events.
Related guides: software engineer interview questions, system design interviews and penetration tester interview questions.
Frequently asked questions
What questions are asked in a web API interview?
What is the difference between safe and idempotent HTTP methods?
What is the difference between 401 and 403?
What is broken object level authorization?
How do you prevent duplicate payments when clients retry?
Sources
- IETF, RFC 9110: HTTP Semantics, sections 9.2.1 and 9.2.2. Read on 2 October 2026.
- MDN Web Docs, HTTP response status codes. Read on 2 October 2026.
- OWASP, OWASP Top 10 API Security Risks – 2023. Read on 2 October 2026.
- Microsoft Learn, Create web APIs with ASP.NET Core. Read on 2 October 2026.