REST API Interview Questions and Answers

Q: What is the difference between PUT and PATCH?

A: PUT replaces the entire resource — you send the complete representation. If a field is missing from the request body, it is removed or reset to its default. PATCH applies a partial update — only the fields you send are modified; everything else stays the same.

# PUT — sends full user object
PUT /users/42
{ "name": "Alice", "email": "alice@example.com", "role": "admin" }

# PATCH — only updates name
PATCH /users/42
{ "name": "Alice Smith" }

Idempotency: PUT must be idempotent. PATCH may or may not be — it depends on implementation (absolute value changes are idempotent; increments like {"views": "+1"} are not).

Q: What does idempotent mean? Which HTTP methods are idempotent?

A: An operation is idempotent if applying it multiple times produces the same result as applying it once. Idempotent HTTP methods:

• GET — Reads data; no side effects
• HEAD — Same as GET but no body
• PUT — Sets resource to the given state; repeating gives the same result
• DELETE — Deletes the resource; deleting again returns 404 but the system state is the same (resource is gone)
• OPTIONS — No side effects

POST is not idempotent — each call typically creates a new resource. This is why retry logic for POST requests requires idempotency keys.

Q: When should you use POST vs PUT?

A: Use POST when the server assigns the resource identifier (most common for creation). Use PUT when the client specifies the resource URL. A simple rule:

• POST /users → server generates ID, returns 201 Created with Location: /users/42
• PUT /users/42 → client specifies ID, creates or replaces the resource

In practice, most APIs use POST for creation and PUT/PATCH for updates.

Q: What is the purpose of the OPTIONS method?

A: OPTIONS is used to discover what methods and headers are supported for a resource. Browsers automatically send a CORS preflight OPTIONS request before cross-origin requests that use non-simple methods or headers. The server responds with Allow and Access-Control-Allow-* headers indicating what is permitted.

Q: What is the difference between authentication and authorization?

A: Authentication is the process of verifying who the caller is (identity). Authorization is the process of determining what the caller is allowed to do (permissions). Authentication happens first. A JWT token, for example, authenticates the caller; the scopes or roles inside the token determine their authorization.

Q: What is a JWT and how does it work?

A: A JSON Web Token (JWT) is a compact, URL-safe token format consisting of three Base64-encoded parts separated by dots: header.payload.signature.

• Header: Token type and signing algorithm (e.g., HS256, RS256)
• Payload: Claims — the data encoded in the token (user ID, roles, expiry)
• Signature: HMAC or RSA signature for tamper detection

JWTs are stateless — the server validates the signature without looking up anything in a database. The trade-off: tokens cannot be revoked before expiry (without a blocklist), so keep expiry times short.

Q: What is OAuth 2.0, and how is it different from API key authentication?

A: API key authentication is simple — the client includes a static key in the request header or query string. It works well for server-to-server communication and internal tools. OAuth 2.0 is a delegated authorization framework. It allows a user to grant a third-party application limited access to their account without sharing their credentials. OAuth 2.0 is the correct choice when:

• A third-party app needs to act on behalf of a user
• You need fine-grained, revocable scopes
• You're building a public API consumed by user-facing apps

Q: Why should API credentials never be sent in the URL?

A: URLs are logged in server access logs, browser history, reverse proxy logs, and Referer headers. Credentials embedded in URLs (e.g., ?api_key=secret) are exposed in all of these locations. Always send credentials in the Authorization header or a custom header, and always over HTTPS.

Q: What is idempotency and why does it matter for API reliability?

A: Idempotency means the same operation can be safely retried without side effects. In distributed systems, requests fail and must be retried. Without idempotency, a network timeout on a payment POST could result in double-charging. Best practices:

• Use idempotency keys for non-idempotent operations (e.g., Idempotency-Key: uuid header)
• Store request results by key for a time window (e.g., 24 hours)
• Return the same response for duplicate requests instead of re-executing

Stripe, PayPal, and most payment APIs implement idempotency keys. See our Idempotency Guide for a full implementation walkthrough.

Q: What is CORS and how does it work?

A: CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts cross-origin HTTP requests. When a browser-based app at app.example.com calls an API at api.other.com, the browser first sends a preflight OPTIONS request. The API server must respond with appropriate Access-Control-Allow-* headers to permit the actual request. Key headers:

• Access-Control-Allow-Origin: * or specific origins
• Access-Control-Allow-Methods: GET, POST, PUT, DELETE
• Access-Control-Allow-Headers: Content-Type, Authorization
• Access-Control-Max-Age: 86400 — cache preflight for 24 hours

Never use Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true — this is a security vulnerability.

Q: How do you design pagination for a REST API?

A: Three main strategies:

• Offset pagination: ?page=2&limit=25 — Simple, but slow on large offsets and unstable under inserts/deletes
• Cursor-based pagination: ?cursor=eyJpZCI6MTAwfQ== — Stable, performant, ideal for real-time feeds (used by Twitter/X, Stripe)
• Keyset pagination: ?after_id=100&limit=25 — Similar to cursor but uses a sortable field; fast indexed queries

Always include pagination metadata in responses: total_count, next/prev links or cursors, and has_more boolean. See our Pagination Guide for implementation details.

Q: What is the difference between REST and GraphQL?

A: REST uses multiple endpoints, each returning a fixed data structure. GraphQL uses a single endpoint where clients specify exactly which fields they want. REST is simpler to cache (HTTP caching works natively), easier to secure per-endpoint, and better for simple CRUD. GraphQL eliminates over-fetching and under-fetching, is excellent for complex, nested data requirements, and is preferred for client-driven UIs. See our REST vs GraphQL comparison for a full breakdown.

Q: How should REST APIs handle errors consistently?

A: A consistent error response format should include: HTTP status code, machine-readable error code, human-readable message, and where applicable, per-field validation errors. The RFC 7807 Problem Details format is increasingly adopted:

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{
  "type": "https://www.restguide.info/errors/validation-error",
  "title": "Validation Error",
  "status": 422,
  "detail": "Request body failed validation",
  "errors": [
    { "field": "email", "message": "Must be a valid email address" },
    { "field": "age",   "message": "Must be 18 or older" }
  ]
}

Q: What is rate limiting, and which headers should your API return?

A: Rate limiting restricts how many requests a client can make in a given time window, protecting the API from abuse and ensuring fair usage. Standard response headers:

• X-RateLimit-Limit: Maximum requests allowed in the window
• X-RateLimit-Remaining: Requests remaining in the current window
• X-RateLimit-Reset: Unix timestamp when the window resets
• Retry-After: Seconds to wait before retrying (on 429 responses)

Common algorithms: token bucket (smooth), fixed window (simple), sliding window (accurate). See our Rate Limiting Guide for implementation details.