REST API Interview Questions and Answers

An architectural style for networked APIs, defined by Roy Fielding. Data is modelled as resources identified by URLs, manipulated through a uniform interface (HTTP methods), and exchanged as representations such as JSON. Communication is stateless and responses can be cached. See What is a REST API.

Client–server, stateless, cacheable, uniform interface, layered system, and (optional) code on demand. The uniform interface includes resource identification, manipulation through representations, self-descriptive messages and hypermedia (HATEOAS). Details in REST constraints.

Each request carries everything the server needs to process it – usually an auth token plus the request data. The server keeps no per-client session between requests, so any instance behind a load balancer can handle any request. Resource state (the data in the database) is still stored, of course.

SOAP is a protocol with a strict XML envelope, WSDL contracts and WS-* standards (security, transactions); it usually sends everything as POST to one endpoint. REST is a style using plain HTTP semantics, any format (mostly JSON), and many resource URLs. REST is lighter and cache-friendly; SOAP still appears in banking and legacy enterprise systems.

GET reads, POST creates (or triggers an action), PUT replaces a whole resource, PATCH updates part of it, DELETE removes it. HEAD is GET without a body; OPTIONS describes allowed methods and is used by CORS preflights. See HTTP methods.

PUT sends the full new state to a known URL and is idempotent. PATCH sends only the changes. POST goes to a collection and the server assigns the id; repeating it creates duplicates, so it is not idempotent.

200 OK, 201 Created (with a Location header), 204 No Content, 400 malformed request, 401 not authenticated, 403 authenticated but not allowed, 404 not found, 409 conflict, 422 validation failed, 429 too many requests, 500 server bug, 503 temporarily unavailable. See status codes.

401 means "we don't know who you are" – missing or invalid credentials; the client should log in. 403 means "we know who you are, and you can't do this"; logging in again won't help.

Plural nouns, lowercase, hyphens, hierarchy only for real ownership: /customers/42/orders. No verbs (/getOrders); the method is the verb. Filters, sorting and pagination go in the query string. See design best practices.

Path parameters identify a resource (/orders/17); query parameters refine a collection or representation (?status=paid&sort=-createdAt&limit=20).

Safe methods don't change server state: GET, HEAD, OPTIONS. Idempotent methods have the same effect whether called once or many times: the safe ones plus PUT and DELETE. POST and PATCH are neither by default. This matters for retries – clients and proxies may safely retry idempotent requests.

Yes. Idempotency is about the state of the server, not the response. After the first call the resource is gone; further calls leave it gone.

With an Idempotency-Key header: the client generates a unique key per operation, the server stores the result under that key and replays it for repeats (and rejects the same key with a different body). Payment APIs work this way. See idempotency keys.

Consistent JSON in every error, ideally RFC 9457 Problem Details (application/problem+json) with type, title, status, detail and field-level errors. Never leak stack traces. See error handling.

Offset (?page=3&limit=20) is simple and supports jumping to a page, but becomes slow on large tables and can skip or repeat items when data changes. Cursor pagination returns an opaque nextCursor pointing after the last item; it's stable and fast, ideal for feeds and infinite scroll. See pagination.

Most common is a major version in the path (/v1/); alternatives are a header or media type. Add fields freely (additive changes are compatible); only breaking changes need a new version. Announce retirement with Deprecation and Sunset headers. See versioning.

The client states what it accepts with Accept (and sends Content-Type for its body); the server picks a representation or returns 406 Not Acceptable / 415 Unsupported Media Type.

Browsers block JavaScript from reading cross-origin responses unless the server allows it with Access-Control-Allow-Origin. Non-simple requests (JSON body, Authorization header, PUT/DELETE) first send an OPTIONS preflight. CORS is a browser rule, not server security – curl ignores it. See CORS explained.

A session id points to state stored on the server – easy to revoke. A JWT is a signed, self-contained token the server verifies without a lookup – scales easily but is hard to revoke before it expires, so keep access tokens short-lived and use refresh tokens. See JWT authentication.

An API key identifies a calling application – fine for server-to-server use. OAuth 2.0 issues scoped, expiring tokens and lets users grant an app limited access without sharing passwords (Authorization Code + PKCE for user apps, Client Credentials for machines). See authentication methods.

The server sends an ETag (a version fingerprint). The client revalidates with If-None-Match; if nothing changed, the server replies 304 Not Modified with no body. Cache-Control decides how long responses may be reused and by whom (private vs public, max-age). See caching and ETags.

Optimistic concurrency: the client sends the ETag it read in If-Match; the server applies the update only if the current version still matches, otherwise returns 412 Precondition Failed and the client reloads. Require it with 428 when missing. See If-Match.

Return 202 Accepted with a Location pointing to a job resource; the client polls it (honouring Retry-After) or receives a webhook when done. The job ends in succeeded (with a link to the result) or failed (with a problem object). See async APIs.

Sign each payload with HMAC-SHA256 using a shared secret, include a timestamp in the signed content, verify with a constant-time comparison, reject old timestamps to stop replays, and make the receiver idempotent because deliveries are retried. See webhooks.

Broken Object Level Authorization – number one in the OWASP API Top 10. An attacker changes an id in the URL (/orders/1002) and reads someone else's data. Prevent it by checking ownership on every object access, typically by scoping queries to the current user, and return 404 rather than revealing the object exists. See security best practices.

Count requests per client (API key, user or IP) in a window – fixed window, sliding window or token bucket – in a shared store such as Redis when you have several instances. Over the limit, return 429 with Retry-After and the RateLimit headers so clients can back off.

Responses include links to related resources and available actions, so clients follow links instead of building URLs. Fully hypermedia-driven clients are rare; in practice you see pagination links, Location headers and action links in some APIs (PayPal, GitHub). It's the top level of the Richardson Maturity Model.

GraphQL when many different clients need flexible, nested data in one round trip. gRPC for fast, strongly typed internal service-to-service calls and streaming. REST remains the default for public APIs thanks to HTTP caching, simple tooling and universality. See REST vs GraphQL vs gRPC.

A machine-readable contract describing endpoints, parameters, schemas and auth. From it you generate documentation (Swagger UI), client SDKs, mock servers and contract tests, and it can be validated in CI so the docs never drift from the code. See OpenAPI.

Unit-test the business logic; run integration tests against the real HTTP layer (status codes, headers, validation, auth failures); add contract tests against the OpenAPI spec, and a few end-to-end smoke tests after deploy. Test the unhappy paths – 400, 401, 403, 404, 409, 422 – as carefully as the happy path. See API testing.