Web API Interview Questions: Complete Guide With Answers
Web API Interview Questions: Comprehensive Guide with Answers
\\n\\n
Web API interviews test your understanding of distributed systems, HTTP protocols, security, and design patterns. Interviewers want to see that you can reason about REST principles, handle real-world constraints like rate limiting and versioning, and make trade-offs between simplicity and scalability. This guide covers the questions you’ll actually encounter, along with answers that go beyond surface-level definitions.
\\n\\n
Whether you’re interviewing for a backend position, a platform team role, or a DevOps engineer spot, API knowledge is non-negotiable. The good news is that most questions follow patterns. Once you understand the principles behind REST, authentication, and performance trade-offs, you can handle variations with confidence.
\\n\\n
REST Fundamentals
\\n\\n
What are the core principles of REST?
\\n\\n
REST, or Representational State Transfer, is an architectural style built on six core constraints. Client and server separation means each can evolve independently as long as they respect the interface contract. Statelessness requires that every request contain all the information needed to process it; the server doesn’t store client context between requests, making it simple to scale horizontally across multiple instances.
\\n\\n
Uniform interface is often the trickiest constraint to explain in an interview. It means every resource should be identified by a unique URI, resources are manipulated through standard representations (usually JSON), and responses should include metadata about state transitions. Cacheability allows responses to define themselves as cacheable or non-cacheable, reducing network traffic. Layered systems let you insert proxies, load balancers, and gateways without breaking the client. Code-on-demand is the least commonly used constraint; it allows servers to extend client functionality by transferring executable code, but most modern APIs skip this.
\\n\\n
The key to answering this well is showing that you understand these constraints aren’t arbitrary. They exist because they solve specific problems: statelessness enables horizontal scaling, cacheability reduces latency, and uniform interface makes APIs predictable and self-documenting.
\\n\\n
Explain statelessness and why it matters for API design.
\\n\\n
A stateless API processes every request without relying on information from previous requests. When a user sends a GET request to fetch their profile, the request must include authentication credentials or a token. The server doesn’t say “I remember this user from the last request.” Instead, it validates the credential in each request independently.
\\n\\n
This has profound implications for scalability. If your API relies on server-side session state, you have two options: sticky sessions that route users to the same server (limiting your ability to scale), or a shared session store like Redis (adding latency and complexity). With statelessness, any server in your fleet can handle any request. You scale by adding more servers, and traffic distributes evenly.
\\n\\n
The trade-off is that request payloads become larger. A stateful system might send a session ID; a stateless system sends a signed JWT that contains claims. For most modern APIs handling thousands of requests per second, the scaling benefit far outweighs the extra bytes.
\\n\\n
Good interviewers ask follow-ups here. “What about user preferences?” Show that preferences come from the request (query parameters) or are included in the response structure. “What if you need to track temporary state?” That’s where databases and caches come in, not server memory.
\\n\\n
How do resources and actions differ in a REST API?
\\n\\n
Resources are nouns; actions are verbs. A REST API should expose resources (users, posts, comments) and let HTTP verbs define what happens to them. A poorly designed API mixes these: GET /getUser, POST /createPost, DELETE /removeComment. A well-designed API treats resources as first-class citizens: GET /users/123, POST /posts, DELETE /posts/456/comments/789.
\\n\\n
This distinction matters because it creates predictability. Any developer can guess the endpoint for fetching a resource if they know the resource type. The HTTP verb tells them immediately whether the operation is safe (GET, HEAD), idempotent (PUT, DELETE), or neither (POST). This consistency reduces cognitive load and makes APIs self-documenting.
\\n\\n
Sometimes you’ll encounter operations that don’t fit neatly into the resource model. “How do I express ‘send a password reset email’?” The answer is to treat it as a resource creation: POST /password-resets with a body containing the email. The API creates a reset token, sends the email, and returns the token or a confirmation. You’re no longer thinking “send email” but “create a password-reset resource.”
\\n\\n
What does idempotency mean and which HTTP methods are idempotent?
\\n\\n
An operation is idempotent if calling it multiple times produces the same result as calling it once. This matters because networks are unreliable. A request might time out before the response returns; the client can safely retry without worrying about double-processing.
\\n\\n
GET, HEAD, PUT, and DELETE are idempotent. GET and HEAD don’t change anything, so they’re trivially idempotent. PUT replaces a resource entirely, so calling it ten times with the same data leaves the resource in the same state as calling it once. DELETE removes a resource; calling it again on an already-deleted resource should return 404, which is a different state, but the critical property holds: repeated calls don’t create multiple deletions or conflicting states.
\\n\\n
POST is not idempotent. Calling POST /orders twice creates two orders. This is why browsers warn you about re-submitting forms. If your API needs to provide idempotent POST operations (to handle network retries), include an idempotency key in the request header. The server checks if it has already processed a request with that key; if so, it returns the cached response instead of processing again.
\\n\\n
The distinction matters for API clients. A well-behaved HTTP client library will automatically retry GET requests on network failures. It will not automatically retry POST requests because retries could have unintended consequences. Some advanced clients allow you to specify idempotency keys for POST operations that should be retryable.
\\n\\n
Explain safe HTTP methods and their purpose.
\\n\\n
Safe methods are those that don’t modify server state. GET and HEAD are safe. DELETE is not safe, even though it’s idempotent, because it modifies state by removing a resource. POST is neither safe nor idempotent.
\\n\\n
The safety distinction matters for caching and retry logic. Safe methods can be cached aggressively without worrying about side effects. Proxies and browsers can prefetch safe requests to optimize perceived performance. A browser might preload the destination of a link using GET before the user clicks it. But GET should never have side effects. If you make DELETE work as a GET parameter (GET /items/123?action=delete), you break these assumptions. A search engine crawler or a browser prefetch could accidentally delete data.
\\n\\n
The technical difference is that safe methods should be read-only. They may do logging or analytics, but they shouldn’t alter application state. This allows clients to reason about safety: if my request is safe, the network can retry it indefinitely, and it won’t cause problems.
\\n\\n
What are the key HTTP verbs and their meanings in REST?
\\n\\n
GET retrieves a resource without modification. POST creates a new resource (the server typically decides the ID) or triggers an action. PUT replaces an entire resource (you send the complete representation). PATCH applies a partial update to a resource (you send only the fields being changed). DELETE removes a resource. HEAD is like GET but returns only headers, no body; useful for checking if a resource exists or has changed without downloading the full content.
\\n\\n
The distinction between PUT and PATCH trips up many developers. PUT is idempotent because it replaces the entire resource. If a field isn’t in your PUT request, it gets set to null or a default. PATCH is not idempotent if you use relative operations (increment a counter), but it’s safer if you only send the fields you’re changing. REST theoretically prefers PUT, but PATCH is practical for large resources where you only want to update one or two fields.
\\n\\n
OPTIONS and TRACE are rarely used in practice. OPTIONS is used for CORS preflight requests and can describe what methods are allowed on a resource. TRACE echoes the request back to the client, primarily for debugging; most APIs disable it for security reasons.
\\n\\n
How should status codes be used in REST APIs?
\\n\\n
HTTP status codes fall into five categories, and using them correctly makes your API much easier to consume.
\\n\\n
2xx codes indicate success. 200 OK means the request succeeded and the response body contains the result. 201 Created means a resource was created; include a Location header pointing to the new resource. 204 No Content means success with no body to return; common for DELETE or PATCH operations that don’t return anything.
\\n\\n
3xx codes indicate redirection. 301 Moved Permanently and 308 Permanent Redirect tell clients to update their bookmarks. 302 Found and 307 Temporary Redirect tell clients to follow the redirect for this request but keep using the original URL next time. 304 Not Modified means the client’s cached version is still valid.
\\n\\n
4xx codes indicate client errors. 400 Bad Request is generic; 400 is overused when more specific codes would be clearer. 401 Unauthorized means authentication is required or invalid. 403 Forbidden means the client is authenticated but not authorized. 404 Not Found means the resource doesn’t exist. 409 Conflict means the request conflicts with current state; useful for optimistic locking scenarios. 422 Unprocessable Entity means the request format is valid but the business logic rejected it (common for validation errors).
\\n\\n
5xx codes indicate server errors. 500 Internal Server Error is the generic catch-all. 503 Service Unavailable means the server is temporarily down. Clients should only retry 5xx errors, not 4xx errors (unless the error is transient like 429 rate limit).
\\n\\n
Best practice is to use the most specific status code available. Don’t default to 400 for everything. If a client provides a malformed JSON body, return 400. If they provide valid JSON but the email field is invalid, return 422 and include details about which field failed validation. This helps API consumers distinguish between their formatting mistakes and their validation mistakes.
\\n\\n
What is content negotiation and how does it work?
\\n\\n
Content negotiation is the mechanism by which a server and client agree on the format of the response. The client sends an Accept header listing the media types it can handle, and the server responds with the format it chose, indicated in the Content-Type header. A client might send Accept: application/json, application/xml, and the server responds with Content-Type: application/json.
\\n\\n
Most modern APIs default to JSON and don’t bother with negotiation. But large enterprises still maintain XML APIs alongside JSON. The Accept header lets a single endpoint serve both without duplication. You can also negotiate on other characteristics: Accept-Language tells the server what language the client prefers, Accept-Encoding indicates compression support (gzip, deflate, brotli).
\\n\\n
Content negotiation reduces code duplication when you support multiple formats. It also makes APIs more flexible for future formats; if you add protobuf support later, clients can opt in by sending Accept: application/protobuf without breaking existing clients.
\\n\\n
How should API versioning be handled?
\\n\\n
There are three main approaches: URL versioning, header versioning, and content-type versioning. URL versioning puts the version in the path: /v1/users, /v2/users. It’s the most obvious to clients and easy to route. Header versioning uses a custom header: Accept: application/vnd.company.v2+json. It keeps the URL clean but is less discoverable. Content-type versioning works similarly but uses the standard Accept header.
\\n\\n
URL versioning has a downside: when you release v2, you must maintain v1 indefinitely or commit to a deprecation timeline. Large companies support three versions simultaneously, with a one-year sunset period. This gets expensive. Some teams argue that good API design eliminates the need for versioning; changes should be additive (new fields in responses, new optional parameters) rather than breaking.
\\n\\n
The practical answer depends on your user base. Internal APIs used only by your own frontend can evolve rapidly; breaking changes are acceptable if you control all clients. Public APIs serving third-party developers need multiple versions and clear deprecation policies. Some companies use feature flags as an alternative to versioning; clients include a header indicating which features they understand, and the API responds accordingly. This scales better than maintaining multiple versions.
\\n\\n
What are best practices for API backward compatibility?
\\n\\n
The core principle is to add, never remove. New API fields should be optional. Old clients that don’t send them should receive default values. Old clients that don’t read new response fields simply ignore them. Breaking changes like removing a field or changing the type of an existing field should be avoided for as long as possible.
\\n\\n
When you must make breaking changes, deprecation is your tool. Document that a field is deprecated in version 1.5, and it will be removed in 2.0. Give clients six months to migrate. Some APIs include a Deprecation header in responses to warn clients about upcoming changes.
\\n\\n
Renaming a field is trickier. If you change “email” to “email_address”, you’re breaking existing clients. Instead, support both names for a period, then deprecate the old name, then remove it. Version numbers should follow semantic versioning: major.minor.patch. Increment major only for breaking changes.
\\n\\n
API Design Questions
\\n\\n
How should URL structure and resource hierarchies be designed?
\\n\\n
URLs should reflect resource hierarchies, but only up to one or two levels. /users/123/posts is clear: the posts belonging to user 123. /users/123/posts/456/comments is getting long and complex. At some point, use query parameters or expand the scope. Instead of /users/123/posts/456/comments, consider /comments?post_id=456.
\\n\\n
Collection endpoints are plural: /users, /posts, /comments. Individual resource endpoints use the ID: /users/123. Avoid mixing: /user/123 is inconsistent. Singular endpoints like /me for the current user are acceptable as special cases but shouldn’t be the pattern.
\\n\\n
Keep URLs simple and readable. A developer should understand what a URL does just by looking at it. /users/123/profile is clearer than /users/123/p. Avoid encoding actions in URLs: /users/123/activate is action-oriented; /users/123 with a PATCH or POST to transition state is more RESTful.
\\n\\n
Use hyphens in URLs, not underscores. /users-groups is more standard than /users_groups. Reserve hyphens for readability and underscores for variable names in code. This is a style preference, but consistency matters.
\\n\\n
Compare pagination strategies: offset, cursor, and keyset pagination.
\\n\\n
Offset pagination sends a limit and offset: /posts?limit=20&offset=40 retrieves posts 40-59. It’s simple to implement and understand. The downside appears with real-time data. If new posts are created between your first request (offset 0) and second request (offset 20), the same post might appear on both pages, or you might skip a post.
\\n\\n
Cursor pagination sends an opaque string that marks a position in the result set: /posts?limit=20&cursor=abc123def456. The server decodes the cursor to determine where the client left off. It handles real-time inserts elegantly because the cursor identifies a specific post, not a numeric position. When new posts are inserted at the beginning of the feed, the cursor still points to the correct post.
\\n\\n
Keyset pagination is similar to cursor pagination but uses the actual values of sort keys. If you’re sorting by created_at, you include the last created_at value from the previous request: /posts?limit=20&since=2026-04-24T10:30:00Z. This is more efficient than decoding opaque cursors but requires that sort keys are stable and unique.
\\n\\n
The tradeoff: offset is simplest but scales poorly and has edge cases with real-time data. Cursor is more complex but eliminates edge cases. Keyset is efficient if your sort keys are suitable. For most modern APIs serving social feeds or time-ordered data, cursor pagination is worth the slight complexity increase.
\\n\\n
How should filtering and sorting be implemented in APIs?
\\n\\n
Filtering uses query parameters: /users?role=admin&status=active. This is clear and easy to implement. The challenge is deciding which fields are filterable. Filtering by every field explodes the query complexity and can expose sensitive information. Document which fields support filtering.
\\n\\n
Use consistent syntax for complex filters. /posts?created_after=2026-01-01&created_before=2026-04-24 is clear. Some APIs use operator syntax: /posts?created=gte:2026-01-01,lte:2026-04-24. This is more compact but less readable. Choose one convention and stick with it.
\\n\\n
Sorting uses a sort parameter: /users?sort=created_at or /users?sort=-created_at (minus for descending). Some APIs use /users?order_by=created_at&order=desc. The key is consistency and documentation.
\\n\\n
Be cautious with combined filters on large datasets. /posts?status=draft&author_id=123&tag=urgent could require scanning millions of rows if these fields aren’t indexed together. Document which filter combinations are efficient. Consider requiring certain filters (author_id is required) to prevent accidental full-table scans.
\\n\\n
Explain request and response envelope patterns.
\\n\\n
An envelope is a wrapper around the actual data. A response might look like this with an envelope:
\\n\\n
{\\n "success": true,\\n "data": {\\n "id": 123,\\n "name": "Alice"\\n },\\n "meta": {\\n "timestamp": "2026-04-24T12:30:00Z"\\n }\\n}\\n\\n\\n
Without an envelope, it’s just the data:
\\n\\n
{\\n "id": 123,\\n "name": "Alice"\\n}\\n\\n\\n
Envelopes provide space for metadata like pagination info, timestamps, and status flags. They make it easier for clients to consistently access metadata without assuming it’s part of the data. The downside is extra nesting and slightly larger payloads.
\\n\\n
Modern APIs tend to skip the envelope. HTTP status codes already indicate success or failure, so the “success” flag is redundant. Timestamps can be HTTP headers. Pagination info lives in a Link header. This reduces response size and keeps responses flatter, which is usually preferable.
\\n\\n
Some teams use envelopes only for collection endpoints (which need pagination metadata) but not for single-resource endpoints. This is a reasonable compromise.
\\n\\n
What is HATEOAS and how important is it in practice?
\\n\\n
HATEOAS stands for Hypermedia As The Engine Of Application State. It means responses should include links to related resources and actions. A user response might include a link to the user’s posts, a link to update the user, and a link to delete the user. Clients follow these links rather than constructing URLs themselves.
\\n\\n
HATEOAS is theoretically elegant because it lets the server evolve URLs without breaking clients. If the server changes the format of post URLs, clients that follow HATEOAS links won’t break; only clients constructing URLs manually will.
\\n\\n
In practice, HATEOAS is rarely implemented in full. Most APIs use it partially: collection responses include a “next” link for pagination, and single-resource responses include a “self” link. Full HATEOAS, where every action is described, adds complexity and verbosity that many teams find unjustified by the benefits.
\\n\\n
If you’re designing an internal API, you can probably skip HATEOAS entirely. If you’re designing a public API, consider implementing partial HATEOAS for pagination and self-links. Full HATEOAS is a reasonable choice if API stability is critical and your clients can handle the extra work.
\\n\\n
How should API documentation be written and maintained?
\\n\\n
OpenAPI (formerly Swagger) is the industry standard. It’s a machine-readable specification that describes endpoints, parameters, request bodies, response schemas, and authentication. Tools like Swagger UI and Redoc generate interactive documentation from OpenAPI specs.
\\n\\n
The benefit of OpenAPI is that it’s a single source of truth. You maintain the spec, and documentation, SDKs, and test mocks are generated from it. The challenge is keeping the spec in sync with the implementation. If you change an API parameter but forget to update the spec, documentation becomes misleading.
\\n\\n
Best practice is to maintain the OpenAPI spec in the same repository as the API code and treat it like code: it requires tests and reviews. Some teams use code-first approaches where the API framework (like Spring Boot or Django) generates the spec from annotations. Others use spec-first approaches where they write the spec first, and the framework validates that the implementation matches.
\\n\\n
Regardless of format, document the “why” behind design decisions. A generated spec tells users that a field exists; good documentation explains what the field represents and when to use it. Include examples of common workflows, error scenarios, and rate limits.
\\n\\n
HTTP and Networking
\\n\\n
Compare HTTP/1.1, HTTP/2, and HTTP/3.
\\n\\n
HTTP/1.1 uses text-based communication and requires a new TCP connection for each request (or connection reuse via keep-alive). Multiple requests block on each other; only one request can use a connection at a time (unless pipelining is enabled, which is rarely used due to head-of-line blocking).
\\n\\n
HTTP/2 multiplexes requests over a single connection. Multiple requests can be in flight simultaneously on the same TCP connection. This reduces latency and connection overhead. HTTP/2 also uses binary framing (more efficient than text) and header compression with HPACK. It requires TLS, and most deployments use HTTPS anyway, so this isn’t a burden.
\\n\\n
HTTP/3 replaces TCP with QUIC, a UDP-based protocol. QUIC is faster to establish connections (fewer round-trips), handles packet loss better (individual streams aren’t blocked by dropped packets like in TCP), and supports connection migration (a client can switch networks and keep the connection alive). HTTP/3 is still rolling out; not all clients and servers support it yet.
\\n\\n
For API design, HTTP/2 adoption has reduced the urgency of techniques like domain sharding and request bundling that were necessary with HTTP/1.1. You don’t need to minimize the number of requests anymore; HTTP/2 handles many requests efficiently. This simplifies API design and client code.
\\n\\n
Explain important HTTP headers: Cache-Control, ETag, Authorization.
\\n\\n
Cache-Control tells caches how long a response is valid. Cache-Control: max-age=3600 means the response is fresh for 3600 seconds. Cache-Control: no-cache means the response must be validated with the server before use. Cache-Control: no-store means don’t cache at all, ever; use this for sensitive data. Cache-Control: public means any cache can store it; private means only the client can cache it.
\\n\\n
ETag is an opaque identifier for a specific version of a resource. When a client has a cached copy, it sends an If-None-Match header with the ETag. The server checks if the resource has changed; if not, it returns 304 Not Modified without sending the full response body. This saves bandwidth. ETags can be strong (byte-for-byte identical) or weak (semantically equivalent); the server indicates which with a prefix like W/.
\\n\\n
Authorization headers carry credentials. Authorization: Bearer token_here is common for token-based authentication. The scheme (Bearer, Basic, etc.) indicates how to interpret the token. The Authorization header is only sent over HTTPS; over HTTP, credentials would be visible to anyone sniffing the network.
\\n\\n
Other critical headers: Content-Type indicates the media type of the response. Accept indicates what the client wants. Vary tells caches which request headers affect the response; Vary: Accept tells a cache that it should store separate copies for different Accept headers. Last-Modified indicates when a resource last changed; it’s an alternative to ETags for simple cases.
\\n\\n
What is CORS and how does it work?
\\n\\n
CORS, or Cross-Origin Resource Sharing, is a mechanism that allows browsers to make requests to APIs on different origins (different domains, ports, or protocols). By default, browsers block cross-origin requests for security. CORS provides a way to opt-in safely.
\\n\\n
When a browser makes a cross-origin request, it first sends a preflight OPTIONS request to check if the server allows it. The server responds with Access-Control-Allow-Origin, Access-Control-Allow-Methods, and other headers. If the server approves, the browser sends the actual request. If not, the browser blocks it.
\\n\\n
For simple requests (GET, HEAD, POST with certain headers), the browser skips the preflight and sends the request directly. The server responds with CORS headers, and the browser checks them. If they don’t allow the request, the browser hides the response from the JavaScript code.
\\n\\n
The practical implication: if your API is at api.example.com and a webpage at www.example.com wants to call it, the page is cross-origin. You must send CORS headers from the API. You can set Access-Control-Allow-Origin: * to allow all origins, but this is only safe for public data. For sensitive data, specify exact origins: Access-Control-Allow-Origin: https://www.example.com.
\\n\\n
A common mistake is setting Access-Control-Allow-Origin: * for an API that uses cookies for authentication. Cookies are automatically sent in requests, so any website can make authenticated requests on behalf of its users. The fix is to use Access-Control-Allow-Credentials: true and specify exact origins instead of *.
\\n\\n
Explain the difference between cookies and tokens for authentication.
\\n\\n
Cookies are automatically sent by the browser with every request to the same domain. They’re simple for stateful sessions: store the session ID in a cookie, and the browser handles the rest. The server stores session data in memory or a database. This works well for traditional web applications.
\\n\\n
Tokens (usually JWTs) are manually managed by the client. The client sends the token in the Authorization header. Tokens can be stateless; the server verifies the token’s signature instead of looking it up in a database. This scales better because the server doesn’t need a session store.
\\n\\n
Cookies have a refresh token problem: when the session expires, the user must log in again. Tokens solve this with refresh tokens: a short-lived access token and a longer-lived refresh token. When the access token expires, the client exchanges the refresh token for a new access token.
\\n\\n
Tokens are better for mobile apps and APIs used by multiple clients. Cookies are simpler for server-rendered web applications. The modern trend is to use tokens everywhere, partly because APIs are being called from diverse clients (web, mobile, third-party integrations) where cookies don’t work reliably.
\\n\\n
Security-wise, both require HTTPS. Tokens should be stored securely on the client (in memory or secure storage on mobile). Cookies should be set with Secure and HttpOnly flags to prevent JavaScript access. A JavaScript-accessible token can be stolen by malicious scripts; an HttpOnly cookie cannot.
\\n\\n
How does connection keep-alive improve performance?
\\n\\n
By default, HTTP/1.1 keeps TCP connections open after a request completes. The client can send another request on the same connection without establishing a new TCP handshake. This saves latency (no SYN-ACK round-trip) and reduces CPU overhead.
\\n\\n
The server closes idle connections after a timeout (typically 30-60 seconds). The client and server negotiate the keep-alive timeout via the Connection header. Connection: keep-alive tells the other side the connection should stay open; Connection: close tells it to close after the request.
\\n\\n
With HTTP/2 and multiplexing, keep-alive is less critical because a single connection can handle many parallel requests. But HTTP/1.1 deployments still benefit significantly from keep-alive. Load balancers and proxies should maintain keep-alive connections to backend services to avoid connection churn.
\\n\\n
Explain TLS handshake and why HTTPS is mandatory for APIs.
\\n\\n
TLS handshake establishes an encrypted connection. The client connects to port 443 and initiates a handshake. The server presents a certificate signed by a trusted certificate authority. The client verifies the certificate, and they negotiate encryption parameters. This takes one round-trip (in TLS 1.3) or more (in older versions).
\\n\\n
HTTPS is mandatory for APIs because HTTP is unencrypted. Any data in transit can be read by attackers on the network. Authentication tokens, API keys, and user data must be encrypted. Most modern browsers and clients refuse to send authentication headers over HTTP.
\\n\\n
TLS also provides integrity checking; the client knows the server hasn’t been compromised because the certificate is valid. A self-signed certificate signals that you’re either developing locally or making a serious security mistake. In production, always use certificates from a trusted CA.
\\n\\n
Some developers worry about TLS overhead. Modern TLS is fast, especially with optimizations like session resumption and TLS 1.3. The security benefits far outweigh any minor performance cost. Always require HTTPS for APIs that handle any sensitive data.
\\n\\n
Authentication and Security
\\n\\n
Explain JWT structure and validation.
\\n\\n
A JWT consists of three parts separated by dots: header.payload.signature. The header specifies the type and signing algorithm. The payload contains claims (arbitrary key-value pairs, often including user ID, roles, expiration). The signature is a hash of the header and payload, signed with the server’s secret key.
\\n\\n
When a client receives a JWT, it can verify it by computing the signature itself using the same secret key. If the signature matches, the client knows the token is genuine and hasn’t been tampered with. The claims are readable (they’re base64-encoded, not encrypted), so don’t put sensitive data in them.
\\n\\n
Validation involves checking the signature, verifying the expiration time (the exp claim), and checking the audience (the aud claim) if the server issues tokens for multiple consumers. Never trust the claims without validating the signature.
\\n\\n
A common mistake is setting exp to a very far future date or omitting it entirely. Access tokens should be short-lived (15-60 minutes) to limit the window an attacker has if a token is stolen. Longer-lived refresh tokens handle persistence.
\\n\\n
JWTs are stateless, which is nice for scaling, but they’re also immutable. If a user’s role changes or a token is compromised, the token remains valid until expiration. To revoke tokens early, maintain a blacklist (trading statelessness for security), or keep TTL short so revocation matters less.
\\n\\n
Describe OAuth 2.0 flows and when to use each.
\\n\\n
OAuth 2.0 defines several flows for delegated authorization. Authorization Code flow is the standard for web applications. A user clicks “Log in with Google.” Your app redirects them to Google’s login page. Google authenticates them and redirects back to your app with an authorization code. Your app exchanges the code for a token by calling Google’s API (backend-to-backend, so the code isn’t exposed to the user). This flow keeps the user’s password away from your application.
\\n\\n
Client Credentials flow is for server-to-server authentication. Your app wants to call another API on its own behalf, not representing a user. Your app sends its client ID and secret to get a token. This is simpler than Authorization Code but only works when there’s no user involved.
\\n\\n
Implicit flow used to be common for single-page applications but is now deprecated due to security concerns. The SPA receives a token directly in the URL fragment, exposing it to JavaScript and the browser history.
\\n\\n
PKCE (Proof Key for Code Exchange) is an extension to Authorization Code flow for mobile apps and SPAs. The client generates a random code, hashes it, and sends the hash. When exchanging the authorization code for a token, the client sends the original code. The server verifies the hash matches, ensuring the code wasn’t intercepted and reused by an attacker. PKCE is now recommended even for traditional server-side apps.
\\n\\n
Resource Owner Password Credentials flow (username and password) should be avoided; it requires users to trust your app with their credentials. Only use it for legacy systems or when you’re authenticating users directly (not delegating to a third party).
\\n\\n
How do API keys differ from OAuth and when should each be used?
\\n\\n
API keys are simple strings that identify the client. The client includes the key in a request header or query parameter. The server looks up the key and authorizes the request. API keys are stateless, simple to implement, and easy to test.
\\n\\n
API keys have limitations. They lack user context; a key identifies a client, not a user. They’re difficult to rotate securely; if a key is compromised, you must invalidate it and generate a new one, updating all clients. They don’t support delegation; you can’t use an API key to grant limited access to a third party.
\\n\\n
OAuth tokens, by contrast, include context (user, client, scope). They can be short-lived. They support delegation. They’re more complex to implement but much more flexible for real-world scenarios.
\\n\\n
Use API keys for simple internal tools and development. Use OAuth for public APIs, third-party integrations, and any system where multiple users or clients interact. Use mTLS (mutual TLS) for highly secure backend-to-backend communication where both parties are known and trusted.
\\n\\n
Explain rate limiting strategies.
\\n\\n
Rate limiting prevents abuse by restricting how many requests a client can make in a time window. The simplest approach is token bucket: imagine a bucket that fills with tokens at a fixed rate. Each request costs one token. When the bucket is empty, requests are rejected. This allows bursts (if the bucket has accumulated tokens) but prevents sustained high traffic.
\\n\\n
Sliding window is another approach: keep track of request timestamps in a time window (e.g., last 60 seconds). If a request would exceed the limit, reject it. This is more precise than token bucket but requires more state.
\\n\\n
Distribute rate limits by client identity: IP address (simple but unreliable if clients share an IP), API key (accurate for API clients), user ID (for authenticated users). Different tiers can have different limits: free users get 100 requests per day, paid users get 10,000.
\\n\\n
Communicate limits to clients via headers. X-RateLimit-Limit tells the client the maximum. X-RateLimit-Remaining shows how many requests are left. X-RateLimit-Reset tells when the window resets. When a client exceeds the limit, return 429 Too Many Requests.
\\n\\n
Store rate limit state in a fast data store like Redis. For distributed APIs with multiple servers, all servers must share the same rate limit state or clients could circumvent limits by distributing requests.
\\n\\n
What are the OWASP API Security Top 10 and how do you defend against them?
\\n\\n
The OWASP API Security Top 10 catalogs common API vulnerabilities. Broken Object Level Authorization happens when an API exposes resources based on user input without checking permissions. An attacker changes a user ID parameter to access another user’s data. Fix: every request must check that the authenticated user has permission to access the resource.
\\n\\n
Broken Authentication means authentication is weak or missing. Endpoints lack authentication, tokens are easy to forge, or credentials are transmitted insecurely. Fix: require strong authentication (OAuth, mTLS), validate tokens properly, use HTTPS.
\\n\\n
Broken Object Property Level Authorization is exposing properties the user shouldn’t see. An API returns all user properties including internal IDs or admin flags. Fix: whitelist which properties are visible to each role or user type.
\\n\\n
Resource Exhaustion happens when clients send requests that consume excessive resources. A query with no pagination could fetch millions of records. A deeply nested GraphQL query could cause the server to do exponential work. Fix: implement rate limiting, pagination limits, and query complexity analysis.
\\n\\n
Broken Function Level Authorization allows users to call functions they shouldn’t. An admin-only endpoint has no authentication check. A disabled feature is still callable via API. Fix: check permissions at the start of every function.
\\n\\n
Mass Assignment happens when a client sets properties that should be read-only. A user updates their role via API by including a role field in the request. Fix: explicitly whitelist which properties can be set; don’t automatically map all request fields to model properties.
\\n\\n
Other top 10 items cover injection attacks, broken asset management, logging failures, and insufficient API versioning. The common theme is that APIs are often less mature than web apps in terms of security. Treat API security seriously; it’s not a secondary concern.
\\n\\n
How should input validation be implemented in APIs?
\\n\\n
Validation happens in layers. At the boundary, validate that the request is well-formed: valid JSON, required fields present, field types correct. This is fast and prevents malformed requests from progressing further.
\\n\\n
Next, validate that values are reasonable. An email field must be a valid email format. A date field must be parseable. A numeric field must fall within expected ranges. An age field shouldn’t be negative or greater than 150.
\\n\\n
Then, validate business logic. Is the email already registered? Is the referenced resource available? Can the user create this resource given their role and quotas? These validations may require database queries.
\\n\\n
Always validate on the server, never rely on client-side validation. Client validation is a nice UX, but attackers can bypass it. Clients can send malicious payloads directly, bypassing your frontend checks.
\\n\\n
Use schemas and libraries to avoid manual validation. JSON Schema can describe request format. Libraries like Joi, Yup, or Pydantic handle validation. This is less error-prone than writing custom validators.
\\n\\n
Be specific in error messages but not too specific. “Invalid email format” is good. “User with email john@example.com already exists” leaks information; attackers can enumerate email addresses. Return “Invalid email or already registered” if you must.
\\n\\n
How do you prevent SQL injection in APIs?
\\n\\n
SQL injection happens when user input is embedded directly into SQL queries without escaping. An attacker provides input like ‘; DROP TABLE users; — and the query executes unintended SQL.
\\n\\n
The fix is parameterized queries (also called prepared statements). Instead of concatenating user input, use placeholders: SELECT * FROM users WHERE id = ?. The database driver replaces the placeholder with the escaped value. The value is never interpreted as SQL code.
\\n\\n
Almost all modern frameworks and libraries use parameterized queries by default. If you’re using an ORM, you usually get protection automatically. If you’re writing raw SQL (which is uncommon but sometimes necessary), always use parameterized queries.
\\n\\n
Other prevention measures: minimize database privileges (don’t use admin credentials for the application), implement input validation, use an ORM to avoid raw SQL. But parameterized queries are the primary defense.
\\n\\n
Performance and Scalability
\\n\\n
Explain caching strategies: CDN, Redis, HTTP caching.
\\n\\n
HTTP caching relies on Cache-Control headers and ETags. Responses are cached by browsers and proxies. Requests for cached responses return immediately without hitting the backend. This is free once implemented; there’s no separate caching layer to maintain.
\\n\\n
Redis is an in-memory data store. Your API stores frequently accessed data in Redis with expiration times. Looking up data in Redis is much faster than database queries. Redis is useful for session state, computed results, and rate limit counters. It’s a single point of failure if not replicated, and it requires memory proportional to the amount of data cached.
\\n\\n
CDNs are geographically distributed. Content is cached at edge locations close to users. Requests are routed to the nearest edge. CDNs excel at static content (images, CSS, JavaScript) and can cache API responses too. The tradeoff is cost and complexity; CDNs are third-party services.
\\n\\n
Combining strategies is common. HTTP caching handles public, cacheable data. Redis caches application-specific data. CDNs cache static assets and cacheable API responses at the edge. Each layer reduces load on the layer beneath.
\\n\\n
Cache invalidation is notoriously difficult. When data changes, caches must be updated or invalidated. Time-based expiration is simple but stale. Event-driven invalidation (invalidate the cache when data changes) is more complex but fresher. Some teams use versioned keys: instead of caching data at “user:123”, they cache at “user:123:version5” and increment the version when data changes.
\\n\\n
How should load balancing be implemented?
\\n\\n
Load balancers distribute traffic across multiple servers. Round-robin sends the next request to the next server in the list. Least connections routes to the server with fewest active connections. IP hash routes based on the client IP, ensuring the same client always reaches the same server (useful for sticky sessions but limits load balancing effectiveness).
\\n\\n
Health checks ensure traffic only goes to healthy servers. The load balancer periodically checks if each server is responsive. If a server doesn’t respond, traffic is routed elsewhere.
\\n\\n
Load balancers can operate at layer 4 (TCP/UDP) or layer 7 (HTTP). Layer 4 is faster but can’t make decisions based on HTTP content. Layer 7 can route based on URL path, hostname, or headers, but it’s more complex and slower.
\\n\\n
Sticky sessions keep a client on the same server. This is necessary if the application uses local session storage. Stateless applications don’t need sticky sessions; any server can handle any request. Removing the stickiness requirement makes scaling much simpler.
\\n\\n
Explain horizontal vs vertical scaling.
\\n\\n
Vertical scaling means making a server more powerful: more CPU, more RAM. It’s simple but has limits. You can’t vertically scale indefinitely; servers top out at some capacity.
\\n\\n
Horizontal scaling means adding more servers. Your application runs on ten servers instead of one. Load balancers distribute traffic. This can scale nearly indefinitely by adding more servers. But it requires stateless application design; if servers have local state, scaling becomes complex.
\\n\\n
Modern cloud platforms favor horizontal scaling. It’s cheaper to add commodity servers than to upgrade to enterprise-grade hardware. It’s more resilient; if one server fails, others continue. It enables gradual capacity expansion.
\\n\\n
APIs should be designed for horizontal scaling from the start. Use external stores for session state (Redis, database), avoid local caching that can’t be shared, and make servers interchangeable.
\\n\\n
What is throttling and how does it differ from rate limiting?
\\n\\n
Rate limiting rejects requests that exceed the limit, returning 429. Throttling delays requests: if a client exceeds the limit, their requests are queued and processed when capacity is available. Rate limiting is stricter and prevents abuse. Throttling is gentler and ensures fairness but can increase latency.
\\n\\n
Rate limiting is more common for public APIs where you want to prevent abuse. Throttling is common internally where you want fairness but not rejection. Some systems use both: throttle up to a point, then rate limit.
\\n\\n
How should asynchronous patterns be used in APIs?
\\n\\n
Synchronous APIs wait for the response before returning. POST /emails with a body containing email content returns after the email is sent. This is simple but if sending takes a long time, the client times out and retries.
\\n\\n
Asynchronous patterns allow the API to return immediately and process the work later. POST /emails returns a request ID immediately (202 Accepted). The client checks the status via GET /email-jobs/request-id or receives a webhook when the job completes. This prevents timeouts and allows processing long-running tasks.
\\n\\n
Use async for operations that take more than a second or two. Sending emails, generating reports, processing large files, training models. Return a request ID or job ID so clients can check status or get notified.
\\n\\n
Explain webhooks vs polling.
\\n\\n
Polling has the client repeatedly ask for updates: GET /order/123 status. Simple to implement but wasteful; most polling requests find nothing new. The client’s experience is delayed; it doesn’t find out about changes until the next poll.
\\n\\n
Webhooks have the server notify the client when something changes. When an order status updates, the server sends a POST request to the client’s webhook URL. This is more efficient and lower latency. The challenge is reliability; the server must retry if the webhook fails, and the client must handle duplicate notifications.
\\n\\n
Use webhooks for real-time notifications (payment status, order shipment). Use polling for status checks that aren’t time-sensitive. Some systems provide both options.
\\n\\n
GraphQL vs REST
\\n\\n
What are the advantages and disadvantages of GraphQL compared to REST?
\\n\\n
GraphQL lets clients request exactly the fields they need. A REST endpoint returns all fields; a GraphQL query returns only requested fields, reducing payload size. REST clients often need multiple requests to fetch related data (user, user’s posts, posts’ comments). GraphQL can fetch related data in a single request via nested queries.
\\n\\n
GraphQL has trade-offs. It’s more complex to implement and learn. Query complexity can spike unexpectedly; a deeply nested query could cause the server to do exponential work. Caching is harder; HTTP caching is ineffective when all requests go to a single endpoint.
\\n\\n
REST is simpler and proven. Standard HTTP caching works. Each endpoint has clear semantics. But REST requires multiple requests and over-fetching (receiving fields you don’t need).
\\n\\n
Choose GraphQL if you have diverse clients with different data needs (web, mobile, different feature sets). Choose REST if your API is simple and homogeneous. Some teams use both; a GraphQL layer wraps internal REST APIs.
\\n\\n
How does the N+1 query problem occur in GraphQL and how is it solved?
\\n\\n
Imagine a GraphQL query that fetches users and each user’s posts. A naive resolver fetches each user (1 query), then for each user fetches their posts (N more queries), resulting in N+1 total queries. If you have 1000 users, that’s 1001 database queries.
\\n\\n
Solutions include batching (fetch all posts in a single query, then match them to users in memory) and dataloader libraries that automatically batch and cache queries. Dataloader collects all requests for related data during execution, fetches them in a single batch query, and caches results.
\\n\\n
When is GraphQL better than REST and vice versa?
\\n\\n
GraphQL excels when clients have heterogeneous needs. A mobile app needs user name and avatar. A web app needs name, avatar, email, and phone. A third-party integration needs only name and ID. GraphQL lets each client request exactly what it needs.
\\n\\n
REST is better when client needs are homogeneous and predictable. If 90% of clients always request the same fields, a REST API with well-designed payloads is simpler and faster than GraphQL.
\\n\\n
GraphQL is harder to cache and harder to rate limit (since all requests go to one endpoint). REST leverages standard HTTP mechanisms. For public APIs prioritizing cacheability, REST often wins. For internal APIs or APIs serving diverse clients, GraphQL often wins.
\\n\\n
gRPC and Other Protocols
\\n\\n
Compare gRPC and REST.
\\n\\n
gRPC uses HTTP/2 and Protocol Buffers (binary format) instead of JSON. It supports bidirectional streaming natively; both client and server can send data independently. It’s faster and more efficient than REST but less human-readable.
\\n\\n
gRPC is excellent for backend-to-backend communication and high-frequency trading systems where every millisecond matters. REST is better for public APIs, browsers, and situations where simplicity and debuggability matter.
\\n\\n
gRPC requires supporting infrastructure (Protocol Buffers compiler, gRPC libraries). REST requires only HTTP, which everything supports. This makes REST more universally compatible.
\\n\\n
What are Protocol Buffers and why use them?
\\n\\n
Protocol Buffers are a language-neutral format for serializing structured data. You define a schema describing the structure (fields, types, nesting). A compiler generates code to serialize and deserialize messages. Protocol Buffers are more efficient than JSON; they’re binary, smaller, and faster to parse.
\\n\\n
Protocol Buffers have built-in versioning; you can add optional fields without breaking old clients. They’re typed, so you catch errors at serialization time rather than runtime.
\\n\\n
The downside is that Protocol Buffers aren’t human-readable. You can’t easily inspect a Protocol Buffer message in a text editor. This makes debugging harder. Use Protocol Buffers for performance-critical backend communication; use JSON for human-facing APIs.
\\n\\n
Describe gRPC streaming types and when to use each.
\\n\\n
Unary is traditional request-response: client sends a request, server responds once. Simple but doesn’t support streaming.
\\n\\n
Server streaming lets the server send multiple messages for a single request. The client sends a request, and the server streams responses back. Useful for fetching large datasets incrementally or pushing notifications.
\\n\\n
Client streaming lets the client send multiple messages to a single server handler. The server processes the stream and responds once. Useful for uploading large files or batch operations.
\\n\\n
Bidirectional streaming lets both sides send messages independently. Useful for real-time communication, chat systems, and multiplayer games.
\\n\\n
When should gRPC be chosen over HTTP/REST?
\\n\\n
gRPC shines in these scenarios: backend-to-backend communication where latency matters, systems handling high request volumes, real-time communication requiring bidirectional streaming, and polyglot environments where Protocol Buffers’ language neutrality matters.
\\n\\n
Avoid gRPC for public APIs, browser clients (gRPC requires HTTP/2 and is harder to debug from the browser), simple CRUD operations where REST’s simplicity suffices, and cases where you need human-readable data formats.
\\n\\n
Testing APIs
\\n\\n
Compare unit testing, integration testing, and end-to-end testing for APIs.
\\n\\n
Unit testing tests individual functions in isolation. You mock external dependencies. A unit test for an API endpoint tests the business logic without hitting a database. This is fast and reliable.
\\n\\n
Integration testing tests components working together. You hit a real database but maybe not external APIs. Tests verify that the endpoint correctly reads from the database, transforms the data, and returns the right response.
\\n\\n
End-to-end testing tests the entire flow from client to database. You test against a staging or test environment. Tests verify that requests succeed, responses are formatted correctly, and data is persisted. These tests are slow but catch real-world issues.
\\n\\n
Good test suites use a pyramid: many unit tests, fewer integration tests, few E2E tests. Unit tests are fast and catch most bugs. Integration tests catch wiring issues. E2E tests verify the happy path and critical user flows.
\\n\\n
What is contract testing and how is it useful?
\\n\\n
Contract testing verifies that an API meets the contract its consumers expect. A consumer records the requests it sends and the responses it expects. The provider tests against these recorded interactions, ensuring the API satisfies the contract. This catches breaking changes before they reach production.
\\n\\n
Pact is a popular contract testing framework. The consumer records expectations in a JSON file (the “pact”). The provider replays the pact against the API, verifying it works. If the provider changes the API in a breaking way, the test fails.
\\n\\n
Contract testing is especially valuable for services with multiple consumers. You ensure the API doesn’t break downstream teams accidentally. Without contract testing, a minor API change deployed on Monday might break a consumer’s midnight batch job on Tuesday.
\\n\\n
How should API mocking be done for testing?
\\n\\n
Mock servers simulate an API for testing purposes. Clients send requests to the mock instead of the real API. The mock returns canned responses based on request matching rules. This is useful when testing client code without depending on a real backend.
\\n\\n
Tools like WireMock (Java), Mockito (Python), and MSW (JavaScript) provide mocking libraries. You define response rules: if the request is GET /users/123, return this JSON. Some tools record requests during development and replay them during testing.
\\n\\n
Mocks should be realistic. If your mock returns responses that the real API would never return, tests pass but real usage fails. Keep mocks synchronized with the real API using contract tests or schema validation.
\\n\\n
How should API load testing be conducted?
\\n\\n
Load testing submits many requests to an API to measure performance under load. Tools like k6, JMeter, and Locust let you define load profiles (number of users, request rate, duration). You measure response times, error rates, and throughput.
\\n\\n
Start with a baseline (what’s the performance when no one is using the API). Then gradually increase load and measure when performance degrades. Identify bottlenecks: is it CPU, memory, database, network? Fix the most impactful bottleneck and test again.
\\n\\n
Load tests should be repeatable and automated. Run them in CI/CD to catch performance regressions. Test against realistic data and traffic patterns, not artificial scenarios. A load test against empty tables gives misleading results.
\\n\\n
What is Postman and how is it used for API testing?
\\n\\n
Postman is a GUI tool for building, testing, and documenting APIs. You create requests, set up collections of related requests, and add tests that verify responses. Postman collections can be version-controlled and run in CI/CD.
\\n\\n
You can extract data from one request and use it in subsequent requests (login, get a token, use the token in later requests). You can parameterize requests and run collections with different data sets. This makes Postman useful for manual testing and simple automated testing.
\\n\\n
Postman is good for quick exploration and manual testing. For comprehensive automated testing, dedicated test frameworks (pytest, Jest) are more powerful. But Postman collections are great for documenting API behavior by example.
\\n\\n
Real-World API Design Scenarios
\\n\\n
Design an API for a social media feed.
\\n\\n
A feed API returns posts ordered by recency or engagement. Endpoints might include GET /feed to fetch the authenticated user’s feed, GET /users/123/posts for a user’s posts, and POST /posts to create a post.
\\n\\n
Key considerations: pagination (cursor-based to handle real-time updates), caching (feed changes frequently, but individual posts can be cached), performance (fetching a feed requires aggregating posts from multiple sources; use denormalization or caching), filtering (show only posts from followed users), and real-time updates (websockets or polling for new posts).
\\n\\n
Designing this well requires considering the write model (how data is stored) and read model (how data is fetched). You might store posts normalized but fetch them denormalized in a feed cache.
\\n\\n
Design an API for a payment system.
\\n\\n
Key endpoints: POST /payments to initiate payment, GET /payments/:id to check status, POST /payments/:id/refund to refund. Security is paramount; all communication must be over HTTPS with TLS. Sensitive data like card numbers should never flow through your API; use a payment processor and tokenization.
\\n\\n
Idempotency is critical. If a payment request times out, the client must be able to retry safely. Include an idempotency key in the request. The server checks if it’s already processed this key; if so, it returns the cached response instead of charging the user again.
\\n\\n
Webhooks notify the client of payment status changes. The client polls GET /payments/:id as a fallback. Database transactions ensure consistency. Extensive logging and monitoring catch fraud and issues.
\\n\\n
Design an API for file uploads.
\\n\\n
Direct uploads go directly from client to cloud storage (S3) using presigned URLs. The client requests a presigned URL, which grants temporary upload permission without storing credentials. The client uploads to S3 directly, bypassing your servers and reducing load.
\\n\\n
Chunked uploads break large files into smaller chunks. The client uploads each chunk via POST /upload/session/:id/chunk/:number. The server reassembles chunks once all are received. This allows resuming partial uploads if the connection drops.
\\n\\n
Security: validate that the uploaded file is the expected type (check MIME type and magic bytes, not just the extension). Scan files for malware. Limit file size to prevent resource exhaustion. Store files outside the web root to prevent arbitrary file execution.
\\n\\n
Design an API for real-time notifications.
\\n\\n
Webhooks push notifications when events occur. The server sends POST requests to client-provided URLs when a relevant event happens. Reliable webhook delivery requires retries, exponential backoff, and idempotency on the client side.
\\n\\n
WebSocket connections allow persistent client-server communication. The server pushes notifications to connected clients immediately. This is lower latency than polling but requires persistent connections and more server resources.
\\n\\n
For at-scale systems, decouple notification sending from the main request handler. An event gets published (user created), a queue picks it up, and a notification worker sends webhooks or broadcasts via WebSocket. This prevents slow notification delivery from blocking the main request.
\\n\\n
Questions to Ask the Interviewer
\\n\\n
What does the typical request look like? High volume? Latency-sensitive? Mobile clients?
\\n\\n
What are the current pain points with the API system?
\\n\\n
How is authentication currently handled?
\\n\\n
How do you handle versioning and breaking changes?
\\n\\n
What tools and frameworks are you currently using?
\\n\\n
What does monitoring and alerting look like?
\\n\\n
How do you approach API documentation?
\\n\\n
See our comprehensive guide to the best answers to interview questions for more insights. Related resources include our guides to Kubernetes interview questions, Kafka interview questions, Terraform interview questions, Snowflake interview questions, quality engineer interview questions, data analyst interview questions, and Glassdoor interview questions.
\\n\\n
Leave a Reply