REST API Interview Questions and Answers

REST (Representational State Transfer) is a style for building APIs. Each resource has a URL, and you use standard HTTP methods to work with it.

Core constraints:

• Client-server: UI and data storage are separated.
• Stateless: each request carries everything needed. The server keeps no session between calls.
• Cacheable: responses declare whether they can be cached.
• Uniform interface: resource URIs, standard methods, representations such as JSON, and (ideally) hypermedia links.
• Layered system: proxies, gateways and load balancers can sit between the client and the server.
• Code on demand (optional): the server can send code to run on the client.

Example: GET /users/42 returns user 42, DELETE /users/42 removes it. Use nouns in URLs and let the HTTP method express the action.

What they are checking: Whether you know the constraints, not only 'it uses JSON over HTTP'

Example mapping for a books collection:

• GET /books list, POST /books create
• GET /books/7 read, PUT /books/7 replace, PATCH /books/7 update fields, DELETE /books/7 remove

Safe means it does not change server state. Idempotent means repeating the call has the same effect as calling it once.

What they are checking: What each method means, including safe and idempotent

PUT replaces the whole resource with the body you send. PATCH applies a partial change to only the fields you send.

Existing user: {"name": "Asha", "email": "[email protected]", "city": "Pune"}

PUT /users/1
{"name": "Asha K", "email": "[email protected]"}

Result: city is gone (the resource is now exactly what was sent), so clients must send the full representation.

PATCH /users/1
{"name": "Asha K"}

Result: only name changes, email and city stay.

• PUT is idempotent by definition.
• PATCH can be idempotent (for example, set a field to a value). But it is not guaranteed (for example, an "increment by 1" operation).
• Prefer PATCH for small edits to large objects. It saves bandwidth and avoids overwriting other people's changes.

What they are checking: Replace vs partial update with an example

POST creates a subordinate resource and the server usually chooses the id. PUT creates or replaces a resource at a URL the client specifies.

Because POST is not idempotent, a client retry after a timeout can create duplicates. That is why payment APIs accept an idempotency key with POST.

What they are checking: Idempotency and who chooses the id

An operation is idempotent if performing it once or many times leaves the server in the same state. The response may be different, but the effect must be the same.

• Idempotent: GET, HEAD, OPTIONS, PUT, DELETE.
• Not idempotent: POST, and PATCH in general.

Example: DELETE /users/5 the first time returns 204 and removes the user. The second time returns 404. But the end state is the same: user 5 does not exist. POST /orders twice creates two orders.

Why it matters: networks fail, so clients and gateways retry. Idempotent calls are safe to retry. For POST, make retries safe with an Idempotency-Key header: the server saves the key with the result. If the same key comes again, it returns the saved result.

What they are checking: Retry-safety reasoning

Grouped by class:

• 1xx informational: 101 Switching Protocols (WebSocket upgrade).
• 2xx success: 200 OK, 201 Created, 202 Accepted (queued for async work), 204 No Content.
• 3xx redirection: 301 Moved Permanently, 302 Found, 304 Not Modified (cached copy valid).
• 4xx client error: 400 Bad Request, 401 Unauthorized (not authenticated), 403 Forbidden (authenticated but not allowed), 404 Not Found. Also 405 Method Not Allowed, 409 Conflict, 422 Unprocessable Content (valid syntax, failed validation), 429 Too Many Requests.
• 5xx server error: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.

Return the most specific code. Never return 200 with an error in the body, because clients and monitoring tools rely on the status.

What they are checking: Precise use of codes

401 Unauthorized means the request lacks valid authentication: no token, an expired token, or wrong credentials. The client should authenticate and retry. Include a WWW-Authenticate header.

403 Forbidden means the server knows who you are but you are not allowed to do this. Logging in again will not help.

Examples:

• Calling /orders with no Authorization header: 401.
• A normal user calling DELETE /users/9: 403.
• Some APIs return 404 instead of 403 when a user should not even know the resource exists. This hides that it exists.

What they are checking: Authn vs authz mapped to codes

Authentication proves who you are. Authorization decides what you are allowed to do.

Analogy: showing your ID at the building entrance is authentication; the badge that opens only certain floors is authorization.

In an API, the token proves identity (authentication). Then the code checks that the user's role or scope allows DELETE /projects/3 and that they own that project (authorization).

What they are checking: Core security distinction

A JSON Web Token (JWT) is a small, signed token that carries information (claims) between two parties. It has three Base64URL parts separated by dots: header.payload.signature.

• Header: algorithm and type, for example {"alg": "RS256", "typ": "JWT"}.
• Payload: claims such as sub (user id), exp (expiry), iss, aud, roles.
• Signature: made from the header and payload with a secret (HMAC) or a private key (RSA/ECDSA).

Flow: the user logs in and the server gives back a JWT. The client sends Authorization: Bearer <token> on later calls. The server checks the signature and expiry, with no session lookup.

Important points:

• The payload is encoded, not encrypted: never put secrets in it.
• Always check the signature, exp, iss and aud. Allow only the algorithm you expect.
• Tokens are hard to cancel before they expire. So keep access tokens short-lived (5 to 15 minutes) and use refresh tokens.

What they are checking: Understanding structure and pitfalls

Never return an unbounded list. Common styles:

Cross-Origin Resource Sharing (CORS) is a browser rule. It controls which other origins can call your API from JavaScript. An origin is scheme plus host plus port. By default, the same-origin policy stops a page on https://app.com from reading responses from https://api.com.

They solve different problems:

Use nouns for resources, plural collections, and let the HTTP method be the verb.

Good:

• GET /users and GET /users/42
• GET /users/42/orders (nested only one or two levels deep)
• POST /users, DELETE /users/42

In a stateful service, the server remembers the client between requests (a server-side session). In a stateless service, every request has all the information needed, such as an auth token and parameters. The server stores nothing about the previous call.

A webhook is an HTTP callback. When an event happens, the provider sends a POST to a URL you registered. Polling means your client keeps asking "anything new?".

Documentation: describe the API with an OpenAPI (Swagger) spec. It lists endpoints, parameters, schemas, auth and error responses. Make interactive docs (Swagger UI, Redoc) and client SDKs from it. Keep the spec in version control. Ideally, create or check it from the code so it stays correct.

• Basic auth: the client sends Authorization: Basic base64(user:password) on every request. It is only Base64 encoded, so you must use HTTPS. The password is sent on every call. It is fine for simple internal tools.
• API key: a long random string that identifies the calling application. It is sent in a header...

• A path parameter identifies one resource: GET /users/42. It is required.
• A query parameter filters, sorts or pages a list: GET /users?role=admin&sort=name&limit=20. Usually optional.
• The request body carries the data to create or update: POST /users with JSON. It is used with POST, PUT and PATCH.
• Headers carry extra information such as auth, content type, idempotency key and version.

A synchronous API holds the connection until the work is done and returns the final result. The client waits.

An asynchronous API accepts the request and replies at once (usually 202 Accepted). The result comes later through polling, a webhook, or a stream.

OAuth 2.0 is an authorization framework. It lets an app use a user's data on another service without getting the user's password. It gives the app an access token with limited permissions (scopes).

Roles: resource owner (user), client (app), authorization server, resource server (API).

Main flows:

• Authorization Code with PKCE: for web, mobile and SPA apps. The user logs in at the provider, and the app trades a code for tokens. This is the recommended default.
• Client Credentials: service-to-service, no user involved.
• Refresh Token: gets new access tokens without a new login.
• Device Code: for TVs and CLIs without a browser.
• Implicit and Resource Owner Password flows are old and should be avoided.

OAuth 2.0 handles authorization. OpenID Connect adds an ID token on top, for login ("Sign in with Google").

What they are checking: Flow choice and the OAuth versus OIDC distinction

Versioning lets you change the API without breaking existing clients. Common strategies:

Rate limiting limits how many requests a client can make in a time window. It protects the service from abuse and overload.

Use the correct status code and a consistent body that programs can read. The standard format is Problem Details (RFC 9457, previously 7807):

OAuth 2.0 answers "what may this app access?" and produces an access token for APIs. OpenID Connect (OIDC) is a small identity layer on top of OAuth 2.0. It answers "who is the user?". It gives an ID token (a JWT) with details about the user.

There is no perfect place; choose by threat model.

A preflight is an automatic OPTIONS request. The browser sends it before the real request when the call is not simple. For example, when it uses PUT/DELETE, a JSON Content-Type, or an Authorization header.

Caching reuses saved responses to cut delay and load. The server controls it with headers.

An API gateway is one entry point in front of the backend services. It handles shared jobs, so each service does not have to.

Advantages:

• Clients ask for exactly the fields they need. This removes extra data and extra round trips.
• One endpoint and a typed schema, with good tools.
• You can change it without versions by marking old fields as deprecated.

HATEOAS stands for Hypermedia As The Engine Of Application State. Responses include links that tell the client what it can do next. The client follows the links instead of fixing the URLs in its code.

An ETag is an identifier for one version of a resource (often a hash or a version number). It is returned in the ETag header.

Caching with conditional GET:

GET /products/5
-> 200, ETag: "v7"
GET /products/5
If-None-Match: "v7"
-> 304 Not Modified (no body, saves bandwidth)

Retry only when it is safe, and spread the retries out.

Treat the API like a product.

PKCE (Proof Key for Code Exchange, said "pixie") protects the authorization code flow. It is for apps that cannot keep a secret, such as browser and mobile apps. It stops an attacker who steals the authorization code from trading it for tokens.

Caching happens at several levels:

• Client: Apollo Client keeps one cache entry per object, found by its type and id. When an object changes, every query that shows it updates. Fetch policies such as cache-first and network-only decide when it asks the server.
• Server: cache hints per field and...

Resources: posts and comments (comments belong to a post).

Use idempotency keys on the non-idempotent POST calls.

Use many layers of defence:

First find the slow part with tracing, logs and database EXPLAIN. Then use the cheapest fix that works.

Postman does not enforce CORS. The browser does. So the problem is in the server response headers.

Do not keep the HTTP connection open. Use the asynchronous request-reply pattern.

The N+1 problem happens when you fetch a list and then run one extra query for each item to load related data. For example, 100 orders with their customers become 101 queries.

Keep old clients working while new ones move over.

Do not send 10,000 separate requests. Do not send one request that times out.