REST API Interview Questions for Backend Engineers: HTTP Semantics, Pagination, Idempotency, and Versioning

REST API interview questions for backend engineers test whether you can turn an HTTP endpoint into a dependable contract. A strong answer connects the method and status code to resource state, retries, concurrency, pagination, security, compatibility, and the evidence you would use in production.

Memorizing GET, POST, and 200 is not enough. Explain duplicates, stable lists under mutation, stale writers, and old clients after a release.

Use Backend Engineer interview questions on PracHub to practice complete backend decisions. The existing API design interview framework is useful for structuring a timed design round; this guide is the implementation-focused question bank for HTTP semantics, pagination, idempotency, caching, versioning, security, and observability.

Quick answer: use Contract, State, Failure, Evolution, Evidence

For every REST API interview question, make five passes:

1. Contract: Name the consumer, resource, operation, request, response, and error shape.
2. State: Identify the authoritative data, invariants, ordering, and concurrency rule.
3. Failure: Trace timeouts, retries, duplicates, stale writes, partial work, and overload.
4. Evolution: Separate additive changes from breaking changes and describe migration.
5. Evidence: Define contract tests, metrics, logs, traces, alerts, and rollout checks.

HTTP semantics interview questions

Which HTTP method should an endpoint use?

Start with the operation's intended semantics. GET and HEAD are safe reads. PUT replaces the state at a client-known resource URI and is idempotent. DELETE is idempotent even if repeated responses differ. POST delegates processing to the target resource and is not inherently idempotent.

The HTTP Semantics standard defines safety and idempotency as method properties, not database implementation details. A strong answer says what a retry means and whether intermediaries may cache the response. Do not use GET for a state change merely because it is convenient.

PUT or PATCH for an update?

Use PUT when the client sends the complete desired representation for a known URI. Use PATCH when the request applies partial-change instructions; define the patch media type and atomicity instead of treating any partial JSON body as self-explanatory. RFC 5789 also explains why conditional requests help prevent collisions.

For either method, define omitted fields, validation errors, and stale-version behavior. PATCH needs a documented merge or operation model.

How do you choose HTTP status codes?

Use the most specific standard code that matches the observable result: 200 OK for a successful response with content, 201 Created plus Location for a created resource, 202 Accepted for work not yet completed, and 204 No Content when no representation is returned.

For errors, distinguish malformed syntax (400), missing or invalid authentication (401), denied authorization (403), absence (404), state conflict (409), failed precondition (412), valid syntax with invalid instructions (422), rate limiting (429), and temporary service inability (503). Return a stable machine code in the body rather than asking clients to parse prose.

Resource boundaries and error contracts

How should REST resources and URLs be modeled?

Model durable nouns and relationships before endpoints: /customers/{id}, /customers/{id}/orders, and /orders/{id}. The server may expose a command-like subresource such as /orders/{id}/cancellations when cancellation is a domain event with its own identity, authorization, audit history, or retry behavior.

Google's resource-oriented design guidance treats resources as the API's conceptual model. Do not leak database tables or internal service boundaries into public URLs. Define identifiers, ownership, lifecycle states, and which transitions are legal.

What should a validation error response contain?

Return one consistent error envelope with a stable type or code, human-readable detail, correlation identifier, and structured field violations when safe. RFC 9457 Problem Details provides standard fields such as type, title, status, detail, and instance that APIs can extend.

Avoid revealing whether another tenant's object exists. Document retryability separately: 409 may require a fresh read, while 429 or 503 may allow bounded retry.

Pagination interview questions

Offset pagination or cursor pagination?

Offset pagination is simple and supports direct page numbers, but large offsets can be expensive and concurrent inserts or deletes can cause duplicates or gaps. Cursor pagination uses an opaque continuation token tied to a stable sort position, making it a better default for changing, high-volume collections.

An internal admin table with small, mostly static results may prefer offsets; a feed or transaction history usually needs a cursor. Explain total-count cost, maximum page size, authorization filters, and reverse navigation.

What makes a cursor stable and safe?

Choose a deterministic total order such as (created_at DESC, id DESC). Encode the last seen sort values, the effective filter and sort contract, and any snapshot or expiry information the server needs. Sign or authenticate opaque tokens so clients cannot change tenant IDs or scan arbitrary positions.

Google AIP-158 requires page tokens to preserve other request parameters. Test equal timestamps, deleted boundary rows, new inserts, expired tokens, changed filters, and empty final pages.

Idempotency and retry questions

How do you make POST safe to retry?

Accept a client-generated idempotency key scoped to the caller and operation. Atomically claim the key, store a canonical request hash, execute the state change, and persist the final response. A retry with the same key and payload receives the original result; reuse with a different payload is rejected.

Stripe's idempotency documentation saves the first result, compares reused parameters, and defines retention. Also define key entropy, sensitive-data rules, and behavior after expiry.

What happens when the same key arrives concurrently?

The idempotency record needs a uniqueness constraint or atomic insert. One request owns execution; another can wait briefly, return an explicit in-progress response, or read the completed result. A check followed by an unprotected insert is still racy.

Commit the business change and idempotency result in one transaction when possible. Use an outbox or durable job for external side effects. State the business invariant under duplicate delivery instead of promising exactly-once execution.

Concurrency, conditional requests, and caching

How do ETags prevent lost updates?

Return a strong ETag representing the resource version. A client reads the resource, then sends If-Match with its update. If the representation changed, the server rejects the write with 412 Precondition Failed instead of silently overwriting a newer value.

Explain how the ETag maps to a database version and which fields affect it. Use 409 Conflict for broader application-state conflicts and 412 when an HTTP precondition failed.

How would you cache a REST response correctly?

Start with who may cache what. Set explicit Cache-Control directives, use Vary for representation dimensions, and use ETag with If-None-Match for revalidation that can return 304 Not Modified. RFC 9111 defines HTTP cache behavior.

Include authorization boundaries, invalidation, staleness tolerance, and cache-key composition. Measure hit ratio, origin latency, stale responses, and revalidation rate.

API versioning and backward compatibility questions

When does an API need a new version?

Do not version every additive change. Adding an optional request field, response field, operation, or header is usually additive if clients tolerate unknown fields. Removing or renaming fields, changing types, adding required input, tightening validation, or changing authorization can break consumers.

Choose URI, header, media-type, or date-based versioning according to the ecosystem, then apply it consistently. GitHub's REST API version policy is a useful example of header-selected, date-based versions with explicit breaking and additive change classes.

How should an API deprecate a version?

Inventory consumers, publish the replacement and migration guide, add compatibility tests, measure usage by version, and give clients a support window. The standardized Deprecation response header can signal that a resource is deprecated; the Sunset header communicates the intended retirement time.

Run both versions long enough to observe real traffic, alert remaining consumers, and rehearse rollback. Return 410 Gone only after the published policy permits removal.

Security and observability interview questions

Which REST API security risks should you discuss?

Separate authentication from authorization and check access at the object and operation level on every request. Validate content type, size, schema, ranges, and upload behavior; limit resource consumption; protect secrets and personal data; and rate-limit by an identity that matches the abuse model.

The OWASP API Security Top 10 highlights object-level authorization, authentication, resource consumption, misconfiguration, and unsafe API consumption. Test that one tenant cannot enumerate or mutate another tenant's resource.

What evidence proves the API works in production?

Measure request rate, success and error classes, latency percentiles, saturation, retries, idempotency conflicts, stale-write failures, pagination-token errors, cache behavior, and dependency timeouts. Use structured logs without secrets, stable request IDs, and distributed traces.

W3C Trace Context standardizes trace propagation, while OpenTelemetry HTTP semantic conventions standardize useful span and metric attributes. Tie alerts to customer symptoms, an owner, a diagnostic view, and a tested response.

Worked example: design an order API

Suppose partners create orders, list history, cancel eligible orders, and receive status changes. Use POST /orders with an idempotency key and return 201 with Location after commit. For asynchronous validation, return 202 plus a pollable state.

Use GET /orders?status=&limit=&page_token= with a signed cursor over (created_at, id). Return an ETag on GET /orders/{id} and require If-Match for a state-changing update when lost updates matter. Model cancellation as a state transition or a cancellation subresource, not an untracked boolean flip.

Authorize the order's tenant on every operation, return Problem Details errors, and emit webhook work through an outbox. Test duplicate creates, cursor boundaries, stale writes, compatibility, tenant isolation, latency, errors, retries, and webhook lag.

Practice REST API judgment on PracHub

These PracHub question-bank records train transferable backend skills. They are practice material, not predictions of your exact interview.

A seven-day REST API interview plan

Day 1: classify methods and justify common status codes. Day 2: model resources, schemas, transitions, and Problem Details. Day 3: implement offset and signed-cursor pagination with boundary tests. Day 4: build a race-safe idempotency table and outbox. Day 5: add ETags and revalidation caching. Day 6: rehearse a version migration. Day 7: deliver the order example using all five passes.

Frequently asked questions

Are REST API interviews different from system design interviews?

Yes. A REST API interview concentrates on the boundary a consumer uses: resources, methods, schemas, errors, retries, compatibility, and security. A system design interview usually expands into storage, queues, deployment, and scale. Strong API answers still explain the storage and failure behavior needed to honor the contract.

Should I memorize every HTTP status code?

No. Know the common success, client-error, overload, and dependency-failure codes, then explain why each matches the observable result. Interviewers care more about consistent semantics and retry guidance than an obscure-code recital. Be precise about similar pairs such as 401 versus 403, 409 versus 412, and 429 versus 503.

Is cursor pagination always better than offset pagination?

No. Cursor pagination fits large, changing collections and sequential navigation. Offset pagination fits small or mostly static results and page jumps. Choose from mutation rate, query cost, ordering, snapshots, and total-count needs.

Does an idempotency key guarantee exactly-once processing?

No. It gives repeated attempts one logical identity and can make the customer-visible result stable. The implementation still needs atomic key ownership, request comparison, transactional state change, durable side-effect delivery, retention, and reconciliation. Explain the invariant you preserve under duplicate delivery instead of promising exactly-once execution everywhere.

Should API versions be placed in the URL or a header?

Either can work. URL versions are visible and easy to route; header or media-type versions keep resource URLs stable; date-based versions make compatibility windows explicit. Consistency, documentation, client tooling, caching, support policy, usage telemetry, and a tested migration path matter more than claiming one universal format.

Final takeaway

The strongest REST API interview answers are precise contracts backed by state and failure reasoning. Use Contract → State → Failure → Evolution → Evidence to choose HTTP semantics, keep pagination stable, make retries idempotent, prevent lost updates, evolve versions, and prove production behavior.

Practice the five linked questions, then use the PracHub Backend Engineer question bank on unfamiliar systems. The goal is not one fashionable URL shape; it is an API whose behavior remains explainable when clients retry, data changes, dependencies fail, and the contract evolves.

Sources and Further Reading

• RFC 9110: HTTP Semantics
• RFC 9111: HTTP Caching
• RFC 5789: PATCH Method for HTTP
• RFC 9457: Problem Details for HTTP APIs
• RFC 6585: Additional HTTP Status Codes
• RFC 9745: Deprecation HTTP Response Header
• RFC 8594: The Sunset HTTP Header Field
• Google AIP-121: Resource-oriented design
• Google AIP-158: Pagination
• Stripe API: Idempotent requests
• GitHub REST API versions
• OpenAPI Specification
• OWASP API Security Top 10, 2023 edition
• W3C Trace Context
• OpenTelemetry semantic conventions for HTTP
• PracHub API Design Interview Framework

Research note: This guide was checked on September 1, 2026. HTTP standards are stable, but vendor policies, API versions, security guidance, and platform behavior can change; verify the current documentation for the interview scenario.