REST API interview questions

Methods and idempotency

• Which methods are idempotent, and which are safe? GET, PUT and DELETE are idempotent; POST is not; GET and HEAD are safe.
• Why it matters: a client that times out and retries must not create two orders. The expected answer involves an idempotency key.
• PUT versus PATCH - full replacement against partial update.
• Is DELETE idempotent if the second call returns 404? Yes - the state after is the same, and being able to argue that is the point.

Status codes

• 200 versus 201 versus 204, and when each applies.
• 400 versus 401 versus 403 versus 422 - and the common confusion between 401 (not authenticated) and 403 (authenticated, not permitted).
• 409 for conflicts, 429 for rate limiting with `Retry-After`.
• Why returning 200 with an error in the body is a bad idea - it breaks every intermediary and client that reads status codes.
• 500 versus 503, and what a client should do differently for each.

Versioning and pagination

• Versioning options - URL path, header, content negotiation - and the practical answer that URL versioning wins on simplicity.
• What is a breaking change? Removing a field, renaming one, tightening validation. Adding an optional field is not.
• Offset versus cursor pagination, and why cursors handle large or shifting datasets better.
• How do you deprecate an endpoint responsibly?

The design exercise

Expect to design an API for something concrete. Work through resources and their URLs, the methods on each, how errors are shaped consistently, authentication, pagination and filtering, and rate limiting. Then say what you would do about retries and partial failure, which is the part most candidates omit. The alternative approach is covered in GraphQL interview questions, and the distributed version in microservices interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and saying what you have not done reads better than bluffing.
• Mid-level: the same ground plus an API you have designed and versioned. Expect follow-ups asking why you made a choice rather than whether you know the syntax.
• Senior: contract evolution across consuming teams, and a migration you ran without breaking clients. The recall questions get shorter and the judgement questions get longer.

Whatever the level, say your answers out loud rather than reading them. Most of what candidates lose in a REST API interview is lost between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common REST API interview questions?

Which HTTP methods are idempotent and why it matters for retries, choosing correct status codes, PUT versus PATCH, versioning strategy and what counts as a breaking change, and pagination for large result sets.

Why does idempotency matter in API design?

Because clients retry. If a request times out after the server processed it, a retry of a non-idempotent operation creates a duplicate - two orders, two charges. The standard mitigation is an idempotency key the server uses to recognise and de-duplicate retries.

What is the difference between 401 and 403?

401 means not authenticated - credentials are missing or invalid, and the client should authenticate. 403 means authenticated but not permitted, so retrying with the same identity will not help. Confusing the two is one of the most common API mistakes.

Should you version an API in the URL or a header?

Both work. URL versioning is the pragmatic default because it is visible, easy to route and easy to test. Header or content-negotiation versioning is purer but harder to debug and cache. Interviewers want the trade-off rather than a doctrine.