REST API questions test whether you can design an interface other people will use without surprises. Below are 20 questions with answers, from the basics to the design details that come up in backend and full-stack interviews. For the HTTP method rules, we followed the definitions in RFC 9110.
Basics
1. What is REST?
REST is an architectural style for networked systems built around resources identified by URLs, manipulated with a small set of standard operations, and described by representations such as JSON. A REST API is stateless: each request carries what the server needs to handle it, so any server can serve any request.
2. What makes an API "RESTful" in practice?
- Nouns for resources in URLs, such as /orders/42, not verbs like /getOrder
- Standard HTTP methods for actions
- Meaningful status codes
- Stateless requests
- Consistent representations and error shapes
In interviews, say that few real APIs follow every REST constraint, and that you aim for predictable behavior.
3. What are the main HTTP methods used for?
| Method | Use | Safe | Idempotent |
|---|---|---|---|
| GET | Read a resource | Yes | Yes |
| POST | Create a resource or trigger an action | No | No |
| PUT | Replace a resource | No | Yes |
| PATCH | Partially update a resource | No | Not guaranteed |
| DELETE | Remove a resource | No | Yes |
"Safe" means the request doesn't change server state. "Idempotent" means sending it several times has the same effect as sending it once.
4. What does idempotent mean, and why does it matter?
If a request is repeated, the end state is the same as after one request. It matters because networks fail. If a client times out on a PUT, it can retry without fear. A POST that creates an order could create two, so APIs often accept an idempotency key: the client sends a unique key, and the server returns the stored result if it sees the key again.
5. PUT or PATCH?
PUT replaces the whole resource with the body you send, and fields you leave out are cleared or reset. PATCH changes only the fields you send. Use PATCH for small updates and PUT when the client holds the full representation.
Status codes and errors
6. Which status codes do you use, and when?
| Code | Use |
|---|---|
| 200 | Success with a body |
| 201 | Created, with a Location header for the new resource |
| 204 | Success with no body, such as a delete |
| 400 | The request is malformed or invalid |
| 401 | Not authenticated |
| 403 | Authenticated but not allowed |
| 404 | Resource not found |
| 409 | Conflict with the current state, such as a duplicate |
| 422 | Well-formed but fails validation |
| 429 | Too many requests |
| 500 | Server error |
| 503 | Service unavailable |
A frequent follow-up is the difference between 401 and 403. 401 means "I don't know who you are", and 403 means "I know who you are, and you can't do this".
7. How should an API return errors?
Use the right status code and a consistent body. A good error body has a stable machine-readable code, a human message, and, for validation errors, which fields failed. Don't leak stack traces or internal details to clients.
8. How do you handle validation?
Validate on the server even if the client validates too. Return all the problems at once when you can, so the user doesn't fix them one at a time, and use 400 or 422 consistently.
Design
9. How do you design URLs for relationships?
Nest when the child only makes sense under the parent, such as /users/7/orders. Keep nesting shallow. Past one or two levels, expose the child directly, such as /orders/42, and filter with query parameters, such as /orders?userId=7.
10. How do you paginate a list?
| Method | How it works | Trade-off |
|---|---|---|
| Offset and limit | ?offset=40&limit=20 | Simple, but slow on large tables and can skip or repeat items when data changes |
| Cursor | ?after=<token>&limit=20 | Stable and fast, but you can't jump to page 50 |
| Page number | ?page=3 | Easy for UIs, with the same issues as offset |
Cursor pagination is the usual answer for large or fast-changing data. Return the next cursor and a hint on whether more results exist.
11. How do you filter and sort?
Use query parameters, such as ?status=open&sort=-created_at. Whitelist the fields you allow, to avoid exposing unindexed or sensitive columns and to keep queries fast.
12. How do you version an API?
| Approach | Example | Note |
|---|---|---|
| In the URL | /v2/orders | Simple and visible |
| In a header | Accept: application/vnd.example.v2+json | Cleaner URLs, harder to test in a browser |
| Query parameter | ?version=2 | Easy, but easy to forget |
Whatever you pick, avoid breaking changes inside a version. Adding fields is usually safe, and removing or renaming fields is not.
13. What is HATEOAS?
Responses include links to related actions, so a client can discover what it can do next instead of hard-coding URLs. It's part of the REST definition, but few APIs implement it fully. Say that you know it and that most teams use documentation and an OpenAPI description instead.
Security and performance
14. How do you authenticate an API?
Common choices are API keys for simple server-to-server use, bearer tokens such as JSON Web Tokens, and OAuth 2.0 when a user grants an app access to their data. Always use HTTPS. Keep secrets out of URLs, since URLs end up in logs.
15. What is the difference between authentication and authorization?
Authentication is proving who you are. Authorization is deciding what you're allowed to do. They fail differently: a missing or invalid token is 401, and a valid token without permission is 403.
16. How do you protect an API from abuse?
Rate limiting per key or per IP, request size limits, input validation, timeouts, and monitoring for unusual traffic. Return 429 with a Retry-After header so clients know when to try again.
17. How does HTTP caching work for APIs?
Responses can carry Cache-Control headers that say how long a response may be reused. An ETag identifies a version of the response. The client sends it back in If-None-Match, and the server answers 304 Not Modified with no body if nothing changed. It saves bandwidth and load.
18. What is CORS?
Browsers block a web page from reading responses from a different origin unless the server allows it. The server sends headers such as Access-Control-Allow-Origin to say which origins may read its responses. It's enforced by the browser, not by the server, so it doesn't protect an API from non-browser clients.
Practical
19. REST or GraphQL or gRPC?
| Good for | Cost | |
|---|---|---|
| REST | Simple, cacheable, widely understood public APIs | Over-fetching and many round trips for complex screens |
| GraphQL | Clients that need to pick exactly the fields and combine data in one request | More server complexity and harder caching |
| gRPC | Fast internal service-to-service calls with strict contracts | Less friendly for browsers and public use |
The best answer names a situation, not a winner.
20. How do you document and test an API?
Describe it with an OpenAPI specification, which can generate documentation and client code. Test at three levels: unit tests for the logic, integration tests against a real database, and contract tests to catch breaking changes. Try the failure cases too, such as invalid input and expired tokens.
How to prepare
- Be able to design a small API on a whiteboard, such as a to-do list or an order system, with URLs, methods, status codes, and one error response.
- Know idempotency and pagination cold. They come up the most.
- Prepare a story about an API you built or used, and one mistake you'd avoid next time.
For related practice, see our guides to Spring Boot interview questions, Node.js interview questions, system design interview questions, and computer networking interview questions.
Practice aloud and in your own words. A transcript afterward shows where you rambled or skipped the point. Follow the employer's rules on AI tools in any live interview or assessment.
Practice your answers with YesToTheOffer
Rehearse out loud, get answers built from your own resume, and review your transcript afterward. 30 free minutes, no subscription.
