Backend EngineeringBackend Engineer I to Senior / Staff15 min read·Updated for 2026 Interview Formats

REST API Design Interview Guide: Authentication, Pagination, Versioning & Rate Limiting

From Resource Modeling to OAuth2, Cursor Pagination & Token Bucket Rate Limiters at Scale

Priya Nair

Ex-FAANG Staff Backend Engineer & API Platform Lead

12+ Years Building Public & Internal REST Platforms

Prep Timeline

3 to 5 Weeks

Format

3 Rounds (API Design, Backend Coding, System Design Deep-Dive)

Conversion

+64% Offer Conversion

REST API Design Interview Guide: Authentication, Pagination, Versioning & Rate Limiting

Executive Summary & Key Takeaways

What You Must Master to Clear This Track

REST is a set of architectural constraints (statelessness, uniform interface, cacheability), not just 'JSON over HTTP' — interviewers probe whether you actually understand the trade-offs behind each one.
Know all three authentication models cold: API keys for service-to-service trust, JWTs for stateless session claims, and OAuth2 Authorization Code + PKCE for delegated third-party access.
Cursor (keyset) pagination beats offset pagination at scale because it avoids re-scanning skipped rows and stays stable when rows are inserted or deleted mid-page.
Version APIs defensively from day one (URI or header versioning) and treat every field addition, removal, or type change as a backward-compatibility decision, not an afterthought.
Idempotency keys and a standardized error envelope are what separate a toy CRUD API from a production-grade contract that survives retries, timeouts, and partial failures.

Structured Preparation Timeline

Step-by-Step Study Plan

Follow this sequential roadmap designed to take you from core foundations to advanced architecture and mock interviews.

Phase 1 (Week 1)

Architectural Constraints, Resource Design & HTTP Semantics

REST Fundamentals & Resource Modeling

Master Roy Fielding's constraints (statelessness, uniform interface, layered system), correct HTTP verb/status code usage, and clean noun-based resource URLs.

Key Milestones

•Design resource hierarchies for a nested domain (e.g. /orders/{id}/line-items) with correct plural nouns and no verbs in URLs.
•Map every CRUD operation to the correct HTTP method and idempotency semantics (GET, PUT, PATCH, DELETE, POST).
•Practice explaining statelessness and its trade-off against convenience features like server-side sessions.

Recommended Actions

•Redesign a legacy RPC-style API ('/getUserById?id=5') into RESTful resource form as a drill.
•Write out the full HTTP status code table (2xx/3xx/4xx/5xx) from memory with one real use case per code.

Phase 2 (Week 2-3)

Security Boundaries, Data Slicing & Long-Term Contract Evolution

Auth, Pagination & Versioning

Deep-dive OAuth2 Authorization Code flow with PKCE, JWT structure and revocation trade-offs, offset vs keyset pagination, and the three major versioning strategies.

Key Milestones

•Trace the full OAuth2 Authorization Code + PKCE handshake end-to-end, including token refresh.
•Implement a cursor-based pagination query using a composite (timestamp, id) key with a supporting index.
•Compare URI versioning, header/Accept versioning, and content negotiation with real backward-compatibility scenarios.

Recommended Actions

•Decode a real JWT on jwt.io and identify which claims are safe to trust without server-side verification.
•Write a migration plan for renaming a field in a v1 API response without breaking existing mobile clients.

Phase 3 (Week 4-5)

Production Hardening for Abuse, Retries & Partial Failure

Resilience: Rate Limiting, Idempotency & Error Contracts

Token bucket vs sliding window rate limiting, idempotency keys for safe retries, standardized error envelopes, and mock interview drills tying it all together.

Key Milestones

•Implement a distributed token bucket limiter backed by Redis and reason about race conditions across app instances.
•Design an idempotency-key mechanism for a payment/charge endpoint that is safe under network retries.
•Draft a single standardized error response shape covering validation, auth, and server errors consistently.

Recommended Actions

•Run 3 mock interviews designing a public API (e.g. a bookings API) end-to-end in 45 minutes.
•Review real-world API docs (Stripe, GitHub, Twilio) and reverse-engineer their pagination, versioning, and error conventions.

Deep-Dive Architecture & Concepts

1. REST Architectural Constraints & Resource Modeling

REST is not 'HTTP plus JSON' — it is a specific set of architectural constraints defined by Roy Fielding's dissertation. Interviewers use resource modeling questions to separate candidates who copy convention from those who understand why the convention exists.

Statelessness

Every request must contain all information needed to process it; the server holds no client session state between requests, which is what enables horizontal scaling behind any load balancer.

Uniform Interface & Resource Nouns

Resources are identified by nouns (/orders/{id}, not /getOrder), manipulated through standard HTTP verbs, and represented in a consistent, self-descriptive media type such as application/json.

Cacheability

Responses explicitly declare whether they are cacheable (Cache-Control, ETag) so clients and intermediary proxies can reduce redundant round-trips without violating correctness.

Layered System & Uniform HTTP Verbs

Clients cannot tell (and shouldn't need to know) whether they are talking directly to the origin server or through a gateway/CDN/cache layer in between.

HATEOAS (Hypermedia as the Engine of Application State)

The most-ignored constraint: responses should include links to valid next actions (e.g. a 'cancel' link on a pending order), letting clients navigate the API dynamically instead of hardcoding URLs.

Interviewer Insights & Pro Tips

When asked to 'design a REST API' in an interview, start by listing resources (nouns) and their relationships before touching a single endpoint path.
Justify verb choices explicitly: PUT is a full idempotent replace, PATCH is a partial (often non-idempotent) update, POST is for creation or non-idempotent actions.

Red Flags & Common Pitfalls

Using verbs in URLs (/createOrder, /getUserDetails) instead of resource nouns with HTTP methods carrying the verb semantics.
Returning 200 OK for every response regardless of outcome, which forces clients to parse the body just to know if something failed.

Deep-Dive Architecture & Concepts

2. Authentication & Authorization: API Keys, JWT & OAuth2

Auth questions test whether you can pick the right trust model for the right relationship: machine-to-machine, first-party session, or third-party delegated access — and whether you understand what each mechanism does NOT protect against.

API Keys

A static secret identifying the calling application (not a user); simple to implement but offers no per-user scoping and must be rotated manually if leaked.

JWT (JSON Web Tokens)

A signed, self-contained token carrying claims (sub, exp, scope) that a resource server can verify statelessly without a database lookup — but that statelessness makes revocation hard before expiry.

OAuth 2.0 Authorization Code Flow + PKCE

The standard for delegated third-party access: a user grants a client application scoped access without ever sharing their password, and PKCE closes the authorization-code-interception hole for public clients (SPAs, mobile apps).

Refresh Tokens & Rotation

Long-lived refresh tokens let a client obtain new short-lived access tokens without re-prompting the user; rotating refresh tokens on every use detects replay/theft.

OAuth 2.0 Authorization Code Flow with PKCE

The end-to-end delegated-authorization handshake used by SPAs, mobile apps, and third-party integrations.

Client Generates Challenge & Redirects

The client app generates a random code_verifier, derives a code_challenge (SHA-256), and redirects the user's browser to the Authorization Server with response_type=code, client_id, redirect_uri, scope, state, and code_challenge.

User Authenticates & Consents

The Authorization Server prompts the user to log in and approve the requested scopes; nothing here ever exposes the resource owner's password to the client application.

Authorization Code Returned

The Authorization Server redirects back to redirect_uri with a short-lived, single-use authorization code and the original state parameter (verified by the client to prevent CSRF).

Client Exchanges Code for Tokens

The client's backend POSTs the code plus the original code_verifier to the token endpoint; the server recomputes the challenge and, on match, issues an access_token, refresh_token, and optionally an id_token.

Client Calls Resource Server

Subsequent API calls attach the access_token as a Bearer credential in the Authorization header; the resource server validates its signature and expiry (or introspects it) before serving the request.

Interviewer Insights & Pro Tips

In interviews, explicitly say why PKCE exists: without it, a malicious app on the same device could intercept the authorization code redirect and exchange it for tokens itself.
Distinguish authentication ('who is this?') from authorization ('what can they do?') — scopes and roles belong to authorization, not the authentication mechanism.

Red Flags & Common Pitfalls

Storing JWTs in localStorage on the client, which is directly readable by any injected XSS script (httpOnly, Secure, SameSite cookies are safer for browser clients).
Treating JWT signature verification as proof the token hasn't been revoked — a stolen-but-unexpired JWT remains valid until a denylist or short expiry catches up.

Deep-Dive Architecture & Concepts

3. Pagination Strategies: Offset vs Cursor/Keyset

Pagination looks trivial until the dataset is billions of rows and users are scrolling an infinite feed — this is one of the highest-signal 'have you actually run this in production' questions in backend interviews.

Offset/Limit Pagination

Simple to implement (OFFSET n LIMIT m) and allows random page jumps, but the database must scan and discard all skipped rows, making deep pages progressively slower.

Cursor / Keyset Pagination

Uses the last seen row's sort key (typically a composite of timestamp + unique id) as an opaque cursor in a WHERE clause, so the database seeks directly to the next page via an index instead of scanning.

Stability Under Concurrent Writes

Offset pagination can skip or duplicate rows if items are inserted/deleted between page requests; keyset pagination stays consistent because each page is anchored to a specific row, not a row count.

Total Count Trade-Offs

Keyset pagination typically cannot cheaply return 'total pages' or support random page jumps — most infinite-scroll UIs (feeds, chat, notifications) don't need that anyway.

Keyset (Cursor) Pagination with a Composite Index

sql

-- Keyset pagination on a composite, unique, indexed key.
  -- The opaque cursor the client holds encodes the last row's (created_at, id).
  SELECT id, title, created_at
  FROM articles
  WHERE (created_at, id) < ($1::timestamptz, $2::uuid)  -- cursor from previous page
  ORDER BY created_at DESC, id DESC
  LIMIT 20;
  
  -- This index turns the WHERE + ORDER BY above into a fast index range scan
  -- instead of a full table scan followed by an in-memory sort.
  CREATE INDEX idx_articles_created_at_id
    ON articles (created_at DESC, id DESC);

Why it matters: Comparing the tuple (created_at, id) directly lets Postgres seek to the correct starting position using the composite index, giving O(log n + page size) performance regardless of how deep the client pages — unlike OFFSET, which degrades linearly with depth. The unique id tiebreaker prevents ambiguity when multiple rows share the same timestamp.

Interviewer Insights & Pro Tips

When asked 'how would you paginate a social feed', immediately reach for cursor pagination and justify it with the insert-during-scroll consistency argument.
Base64-encode the cursor (e.g. {created_at, id}) so it's opaque to clients — this lets you change the underlying sort key later without breaking the API contract.

Red Flags & Common Pitfalls

Using OFFSET on a table with millions of rows for deep pages, causing full scans that get slower with every page the user requests.
Exposing raw internal IDs or unencoded sort keys as the cursor, which leaks implementation details and breaks if the schema changes.

Deep-Dive Architecture & Concepts

4. Versioning, Rate Limiting, Idempotency & Error Contracts

The last mile of API design is what keeps a contract alive for years: how you evolve it without breaking clients, how you protect it from abuse, and how you make it safe to retry when the network fails halfway through a request.

URI vs Header vs Content-Negotiation Versioning

URI versioning (/v1/orders) is explicit and cache-friendly but clutters URLs; header versioning (Accept: application/vnd.api.v2+json) keeps URLs stable but is less discoverable and harder to test in a browser.

Backward-Compatible Evolution

Adding optional fields is safe; renaming, removing, or changing the type of an existing field is a breaking change that requires a new version or a carefully staged dual-write/dual-read migration.

Rate Limiting Algorithms

Token bucket allows controlled bursts while enforcing an average rate; sliding window log/counter gives smoother, more precise limits than fixed windows, which suffer from boundary burst spikes.

Idempotency Keys

A client-generated key (e.g. Idempotency-Key header) lets a server safely deduplicate retried POST requests — critical for payments, order creation, and any non-idempotent side effect over an unreliable network.

Standardized Error Envelope

A consistent { error: { code, message, details, requestId } } shape across every endpoint lets client SDKs handle errors generically instead of branching per-endpoint.

Distributed Token Bucket Rate Limiter (Redis + Lua)

typescript

// Atomic token bucket implemented as a Redis Lua script so concurrent
  // requests across many stateless app instances never race on read-modify-write.
  import { Redis } from "ioredis";
  
  const redis = new Redis(process.env.REDIS_URL);
  
  const TOKEN_BUCKET_SCRIPT = `
  local key = KEYS[1]
  local capacity = tonumber(ARGV[1])
  local refillRatePerSec = tonumber(ARGV[2])
  local now = tonumber(ARGV[3])
  local requested = tonumber(ARGV[4])
  
  local bucket = redis.call("HMGET", key, "tokens", "timestamp")
  local tokens = tonumber(bucket[1])
  local lastRefill = tonumber(bucket[2])
  
  if tokens == nil then
    tokens = capacity
    lastRefill = now
  end
  
  local elapsed = math.max(0, now - lastRefill)
  tokens = math.min(capacity, tokens + elapsed * refillRatePerSec)
  
  local allowed = tokens >= requested
  if allowed then
    tokens = tokens - requested
  end
  
  redis.call("HMSET", key, "tokens", tokens, "timestamp", now)
  redis.call("EXPIRE", key, 3600)
  
  return allowed and 1 or 0
  `;
  
  export async function isRequestAllowed(
    clientId: string,
    capacity = 100,
    refillRatePerSecond = 10,
  ): Promise<boolean> {
    const now = Date.now() / 1000;
    const result = await redis.eval(
      TOKEN_BUCKET_SCRIPT,
      1,
      `rate_limit:${clientId}`,
      capacity,
      refillRatePerSecond,
      now,
      1,
    );
    return result === 1;
  }

Why it matters: Running the read-refill-check-decrement logic as a single Lua script makes the whole operation atomic on the Redis server, eliminating the race condition where two app instances both read 'tokens remaining' before either decrements it. The bucket refills continuously based on elapsed time rather than resetting on a fixed clock boundary, which avoids the burst-at-window-edge problem of naive fixed-window counters.

Interviewer Insights & Pro Tips

When comparing rate limiting algorithms, lead with the trade-off: fixed window is cheapest but allows 2x burst at window boundaries; sliding window log is most accurate but costs more memory per key; token bucket is the pragmatic middle ground most APIs (Stripe, GitHub) actually ship.
Always return 429 Too Many Requests with a Retry-After header (and ideally X-RateLimit-Remaining/X-RateLimit-Reset) so well-behaved clients can back off automatically.

Red Flags & Common Pitfalls

Storing rate limit counters in local process memory in a horizontally scaled fleet, which lets each instance independently allow up to the limit — multiplying the effective limit by the instance count.
Making a payment or order-creation endpoint retry-unsafe by relying only on client-side 'don't double click' UX instead of a server-side idempotency key.
Breaking existing clients by silently changing a field's type or removing it in the current API version instead of introducing a new version or an additive migration.

Real-World Example

Migrating a Booking Platform's API from Offset Pagination to Cursor Pagination Under Load

A mid-size travel booking platform's public search API used simple OFFSET/LIMIT pagination on a `listings` table that had grown from 200K to 40M rows over two years. During peak season, partner integrations paginating deep into search results (page 200+) were timing out and causing database CPU spikes that degraded the primary booking flow.

1The team instrumented slow query logs and confirmed OFFSET-heavy queries on deep pages were responsible for over 30% of database CPU during peak traffic windows.
2They introduced a new cursor-based pagination parameter (`after` cursor encoding a base64 {sort_score, id} tuple) alongside the existing offset parameter, keeping the old behavior available under a deprecation notice rather than breaking partners immediately.
3A composite index on (sort_score DESC, id DESC) was added to support the new keyset queries as fast index range scans instead of full sorts.
4Partner-facing documentation and SDKs were updated with a 90-day migration window, and a `Deprecation` response header was added to every offset-paginated response to nudge automated clients.
5The team monitored per-partner API version usage via a dashboard, reaching out directly to the last handful of integrations still on offset pagination before the sunset date.
6Old OFFSET-based endpoints were removed only after usage dropped below 1% of total traffic for two consecutive weeks.

Outcome: Peak-season database CPU attributable to pagination queries dropped by roughly 70%, and deep-page search latency for partner integrations improved from several seconds to consistently under 100ms.

Real-World Interview Questions

Mistakes That Sink Otherwise Strong Candidates

Designing URLs around verbs and actions instead of nouns (/getOrders, /createUser).

Why it happens: Developers coming from RPC-style or SOAP backgrounds default to function-call thinking, mapping each server operation directly to a URL.

The fix: Model resources as nouns and let the HTTP method carry the verb: GET /orders, POST /users. Reserve action-style sub-paths (POST /orders/{id}/cancel) only for state transitions that don't map cleanly to CRUD.

Using OFFSET/LIMIT pagination on a large, frequently-growing table without ever revisiting the decision.

Why it happens: Offset pagination is the simplest thing to implement and works fine in development with small seed data, so the performance cliff only appears once the table reaches production scale.

The fix: Default to cursor/keyset pagination for any resource expected to grow past a few hundred thousand rows or be paged deeply, backed by a composite index matching the sort order.

Storing JWTs in browser localStorage for a single-page app.

Why it happens: localStorage is the easiest storage API to reach for and 'just works' in a quick demo, without the developer considering the XSS attack surface.

The fix: Store tokens in httpOnly, Secure, SameSite cookies so client-side JavaScript (and any injected XSS payload) cannot read them directly.

Rate limiting using an in-memory counter inside each application server process.

Why it happens: It's the fastest thing to prototype locally, and the bug is invisible until the service is actually scaled to multiple instances in production.

The fix: Back the rate limiter with a shared store (Redis) and update counters atomically (Lua script or atomic commands) so the limit is enforced fleet-wide, not per-instance.

Treating a field rename or type change as a 'minor fix' shipped directly into the current API version.

Why it happens: The change looks small and internally consistent to the team making it, without accounting for external clients already depending on the old shape.

The fix: Classify every response/request shape change as additive or breaking before shipping; breaking changes go through a new version or an explicit expand-and-contract migration with a deprecation window.

Allowing a POST endpoint that charges a card or creates an order to be re-executed freely on client retry.

Why it happens: The unhappy path (network timeout right after the server processed the request but before the client got the response) is rarely tested, so double-execution only surfaces in production incident reports.

The fix: Require an Idempotency-Key on any non-idempotent, side-effecting endpoint, and store the key-to-result mapping so retries return the original result instead of re-executing.

Returning 200 OK with an `{ success: false }` body instead of the correct 4xx/5xx status code.

Why it happens: It feels 'simpler' to always return 200 and let clients check a boolean, especially when a frontend team drives the API contract informally.

The fix: Use accurate HTTP status codes as the primary signal of outcome (400/401/403/404/409/422/429/500) so infrastructure (caches, load balancers, monitoring, client libraries) can react correctly without inspecting the body.

Inventing a different, inconsistent error response shape per endpoint or per team.

Why it happens: Endpoints are often built by different engineers or teams over time without a shared contract enforced up front.

The fix: Define one standardized error envelope ({ error: { code, message, details, requestId } }) at the platform level and enforce it via shared middleware or a schema/lint check in CI.

Assuming JWT signature verification means the token is still valid and unrevoked.

Why it happens: Signature checks are the most visible part of JWT handling, so it's easy to treat 'signature valid' as equivalent to 'access still authorized'.

The fix: Keep access token lifetimes short (minutes, not days), verify a token-version or denylist claim for sensitive operations, and rely on revocable refresh tokens for the actual logout/revocation guarantee.

Cheat Sheet

Quick-Reference Cheat Sheet

HTTP Status Codes — When to Use Which

200 OKSuccessful GET, PUT, or PATCH with a response body.

201 CreatedSuccessful POST that created a new resource; include a Location header.

204 No ContentSuccessful DELETE or action with no response body to return.

400 Bad RequestMalformed syntax, missing required fields, invalid types.

401 UnauthorizedMissing or invalid authentication credentials — 'who are you?'

403 ForbiddenAuthenticated but not permitted to perform this action.

409 ConflictState conflict, e.g. optimistic-locking version mismatch.

422 Unprocessable EntityWell-formed request that violates a business rule.

Pagination Strategy Comparison

Offset/LimitSimple, supports random page jumps; O(offset) cost, unstable under concurrent writes.

Cursor/KeysetAnchors to last row's key; O(log n) via index seek, stable, no random page jump.

Best for offsetSmall or rarely-changing tables (admin panels, config lists).

Best for cursorFeeds, infinite scroll, high-growth tables, chat/notification history.

Cursor encodingBase64-encode the composite (sort_key, id) tuple to keep it opaque.

Rate Limiting Algorithm Comparison

Fixed WindowCheapest; allows up to 2x burst at window boundaries.

Sliding Window LogMost accurate; higher memory cost storing per-request timestamps.

Sliding Window CounterApproximates sliding log cheaply by weighting adjacent windows.

Token BucketAllows bounded bursts up to capacity, enforces steady average rate; most common production choice.

Leaky BucketSmooths bursts into a strictly constant output rate via a processing queue.

API Versioning Strategy Comparison

URI Versioning (/v1/...)Explicit, cache-friendly, easiest to test manually; most widely used in practice.

Header VersioningKeeps URLs stable; less discoverable, harder to test in a plain browser.

Content Negotiation (Accept: vnd.api.v2+json)Most 'RESTfully pure'; least ergonomic for typical API consumers.

Additive ChangeNew optional field/endpoint/param — safe without a version bump.

Breaking ChangeField removed/renamed/retyped, or required-ness tightened — needs a new version.

Auth Mechanism Comparison

API KeyBest for service-to-service trust; no per-user scope; manual rotation on leak.

JWTStateless, self-verifying claims; hard to revoke before expiry.

OAuth2 + PKCEDelegated third-party access without sharing credentials; standard for user-consent flows.

Refresh TokenLong-lived, server-revocable; used to mint new short-lived access tokens.

401 vs 403401 = not authenticated; 403 = authenticated but not authorized.

Idempotency & Error Contract Essentials

Idempotent MethodsGET, PUT, DELETE, HEAD, OPTIONS — same result no matter how many times repeated.

Non-Idempotent MethodsPOST, and PATCH in the general case — must be explicitly guarded for retries.

Idempotency-Key HeaderClient-generated unique key per logical action; server stores first result and replays it on retry.

Error Envelope{ error: { code, message, details, requestId } } — consistent across every endpoint.

429 ResponsePair with Retry-After and X-RateLimit-* headers so clients can self-throttle.

Assessment Integration

Recommended Practice Quizzes on QuizCluster

Test your retention and prepare for timed live coding and MCQ technical screening rounds:

620 Quizzes

JavaScript & TypeScript

Sharpen the TypeScript and async patterns behind real Node.js REST API implementations, from middleware to error handling.

Start Practice Test

28 Scenarios

High-Level System Design (HLD)

Practice designing rate limiters, API gateways, and pagination-heavy services at scale for senior system design rounds.

Start Practice Test

Frequently Asked Questions

Is GraphQL replacing REST in interviews?

No — REST remains the dominant interview topic because most companies' production APIs are still REST-based, and REST design questions (auth, pagination, versioning, rate limiting) test fundamentals that transfer to GraphQL and gRPC as well. Expect GraphQL to come up as a comparison question, not a replacement topic.

Do I need to memorize every HTTP status code for interviews?

No, but you should know the common ones cold: 200/201/204 for success variants, 400/401/403/404/409/422 for client errors, and 429/500/503 for rate limiting and server failure. Interviewers care more about WHY you'd pick 422 over 400 than whether you've memorized all 63 official codes.

Should I bring up rate limiting and idempotency even if not explicitly asked?

Yes — proactively mentioning rate limiting, idempotency, and error contracts when designing any endpoint that writes data (especially payments or order creation) is a strong signal of production experience and is exactly what separates mid-level from senior-level answers.

How deep should I go on OAuth2 if the role isn't security-focused?

Know the Authorization Code + PKCE flow well enough to draw it from memory and explain what each step prevents (CSRF via state, code interception via PKCE) — you don't need to memorize every OAuth2 grant type (implicit, client credentials, device code) in equal depth unless the role is specifically security or platform-focused.