REST API Interview Questions

Model answer

A method is idempotent when sending the same request once or ten times leaves the server in the same state. The response can differ (a second DELETE may return 404), but the effect does not stack.

GET, PUT and DELETE are idempotent: reading changes nothing, PUT sets a resource to a value, and deleting twice is still one deletion. POST is not: two POST /orders normally create two orders. PATCH is not guaranteed either, because "add 1 to quantity" stacks.

It matters because networks fail mid-request, and clients, proxies and load balancers retry. Retrying an idempotent call is safe; retrying a POST needs extra work.

Model answer

The client cannot tell whether the first request failed or only the response got lost, so the server must make the retry harmless. Use an idempotency key: the client generates a unique key (a UUID) per payment attempt and sends it in a header such as Idempotency-Key.

The server stores the key with the result of the first request. When the same key arrives again, it skips the charge and returns the stored response. A different key means a genuinely new payment.

The key is scoped to the customer or API account, so one user cannot replay another's key, and the stored request body is compared so a reused key with different data is rejected with an error instead of silently returning the old result.

Model answer

Check-then-insert is a race. The fix is to make claiming the key a single atomic step that only one request can win.

Insert the key first, with a unique constraint, in a "processing" state, before doing any work. The database lets exactly one insert succeed; the loser gets a constraint violation and knows another request owns the key.

INSERT INTO idempotency_keys (account_id, key, status, request_hash)
VALUES ($1, $2, 'processing', $3)
ON CONFLICT (account_id, key) DO NOTHING
RETURNING id;  -- no row back means someone else already holds it

The winner does the charge and updates the row with the response. A Redis SET key value NX works the same way if the store is Redis, but the database is safer when the payment itself is written there, because the claim and the result can share a transaction.

Model answer

While the first request is still running, return 409 Conflict (or 425/429 with Retry-After) and let the client retry later. Do not start a second charge and do not block the connection for a long time.

A crash halfway is the hard case: the row says "processing" forever. Store a timestamp and treat processing rows older than a timeout as abandoned. Before redoing the work, ask the payment provider whether the charge went through, using your own key as the provider's idempotency key, so the provider deduplicates too. That is why the key should be passed all the way down the chain.

Keep keys for at least the client's retry window, commonly 24 hours (Stripe uses 24h), then delete them with a TTL or a cleanup job. Keeping them forever only grows the table; deleting them too early reopens the double charge.

Model answer

Offset pagination takes ?limit=20&offset=40 and runs ORDER BY ... LIMIT 20 OFFSET 40. It is simple and lets users jump to page 7, but the database still reads and throws away the skipped rows, so deep pages get slow.

Cursor (keyset) pagination returns an opaque cursor that encodes where the last page ended, and the next query starts after it: WHERE created_at < :last ORDER BY created_at DESC LIMIT 20. With an index this costs the same on page 1 and page 10,000.

Rule of thumb: offset for small admin tables where page numbers matter, cursors for feeds, APIs and anything large or changing.

Model answer

Offsets are positions, and positions shift. If 3 new orders are inserted at the top while the user is on page 1, page 2 starts 3 rows earlier than it should, so the user sees 3 orders twice. Deletions do the opposite and rows are skipped.

A cursor is anchored to a value, not a position: "orders older than this one". New rows at the top do not move that anchor, so the next page continues exactly where the last one stopped.

Model answer

If ten rows share the last timestamp, created_at < :last skips the ones not yet shown, and <= repeats the ones already shown. The sort needs a unique tie-breaker, usually the primary key.

Order by both columns and compare them as a pair. The cursor carries both values, base64-encoded so clients treat it as opaque.

SELECT * FROM orders
WHERE (created_at, id) < (:last_created_at, :last_id)
ORDER BY created_at DESC, id DESC
LIMIT 20;

Back it with an index on (created_at, id) in the same order, so the query is an index range scan. Row-value comparison works in Postgres and MySQL; elsewhere, expand it to created_at < a OR (created_at = a AND id < b).

Model answer

Each filter-and-sort combination needs its own index with the equality columns first and the sort columns after: (status, amount, id). Then WHERE status = :s AND (amount, id) < (:a, :id) ORDER BY amount DESC, id DESC is a range scan. Support a small set of sorts on purpose rather than every combination, because every index slows writes.

Jumping to page 500 is offset by another name: the database must count through 10,000 rows to find it. Push back with what users actually need: nobody reads page 500, they narrow the search (a date range, an amount range, a search box). If exact page numbers are a must, cap the depth (many sites stop at 100 pages) or precompute snapshots for exports.

Showing "about 4.2 million results" can come from an estimate (Postgres planner stats) instead of an exact COUNT(*), which is a full scan at that size.

Model answer

With sessions, the server stores who is logged in (in memory, Redis or a database) and gives the browser a random session id in a cookie. Every request looks the id up. Logging out deletes the record.

With JWTs, the server signs a token holding the user id, roles and an expiry, and stores nothing. Any server with the key can verify the signature and trust the claims without a lookup, which suits many services and stateless scaling.

The trade: sessions are easy to revoke but need a shared store; JWTs need no lookup but cannot be taken back before they expire, and anything inside them can be read (signed is not encrypted).

Model answer

A signed token stays valid until exp, so you have to add some state back. The usual options:

• Short expiry (5 to 15 minutes) so a stolen token dies quickly, paired with refresh tokens.
• A denylist of revoked token ids (jti) in Redis, each kept only until that token's exp. Every request checks it, which is a lookup again, but a cheap one.
• A token version per user: put ver in the token and bump it in the database on logout or password change. Tokens with an old version are rejected. One counter logs out every device.

Being honest about it in an interview helps: once you need instant revocation everywhere, you have rebuilt sessions, and that is fine.

Model answer

The access token is short-lived and sent on every API call. The refresh token is long-lived and used only to get a new access token from the auth server. Keeping access tokens short limits the damage of a leak; the refresh token keeps the user logged in.

In a browser, the refresh token belongs in an HttpOnly, Secure, SameSite cookie scoped to the refresh endpoint: JavaScript cannot read it, so an XSS bug cannot steal it. The access token is best kept in memory (a variable), not localStorage, which any injected script can read.

Cookies bring CSRF into play, so the refresh endpoint should check SameSite plus an origin check or CSRF token. Many teams skip storing tokens in the browser at all with a backend-for-frontend that keeps tokens server-side and gives the browser a session cookie.

Model answer

Use refresh token rotation: every refresh returns a new refresh token and invalidates the old one. All tokens from one login belong to a "family".

Then add reuse detection: if an already-used refresh token is presented, someone has a copy. Either the attacker or the real user is replaying it, and you cannot tell which, so revoke the whole family. Both get logged out; the real user signs in again, the attacker is locked out. This is what the OAuth security best-practice guidance recommends for public clients.

Around that: bind the family to a device record, keep an absolute lifetime (say 30 days) even with rotation, alert on refreshes from a new country, and revoke all families on password change.