No matter which programming language or technology you’re working with, you’ve probably encountered a REST application programming interface (API). REST stands for Representational State Transfer, which is the one of the most widely-used architectural styles for web services, microservices, and APIs today. APIs that follow the REST architectural style are considered REST APIs.
Whether you’re a junior or senior developer, you may be asked questions about REST API in an interview. To help you ace your next interview, we’ll discuss some common REST API interview questions and answers.
We’ll cover:
A REST API or RESTful API is a web API that conforms to the REST architecture style.
In case they ask for 6 constraints, see the following question about the optional constraint.
A truly RESTful API must conform to the five REST architectural constraints:
Code on demand is the optional constraint of RESTful architecture. Code on demand allows the server to send executable code (scripts or applets) to a client upon client request.
Advantage: Extends client functionality, since client can download features after deployment
Disadvantage: Reduces visibility, which is why it’s considered optional
Examples: Java applets and JavaScript
A uniform interface is needed to decouple the client from the server.
There are four necessary constraints to achieving uniform interface:
REST APIs are based on HTTP requests or verbs, which each perform a different task.
REST supports the following HTTP requests:
This question can stump some developers. Being able to explain this will help you stand out as someone who actually knows what they’re talking about.
Here are the differences between PUT and POST:
PUT:
POST:
Understanding idempotency: An example of an idempotent operation would be the operation of multiplying a number by one. No matter how many times you multiply five by one, you’ll get the same result.
Statelessness means that the client and server don’t store information about each other’s state. Since the server stores no information, it treats each client request as a new request.
As a consequence, the following conditions would apply:
It’s important to know the pros and cons of a RESTful API.
Advantages include:
Disadvantages include:
The distinction can confuse beginner developers, so it’s helpful to know the difference.
An AJAX client can make a RESTful request to a REST API (e.g. a get request), but AJAX isn’t an architectural style. It’s a web development technique for client-side applications. REST APIs can be accessed by AJAX clients, but they aren’t inherently implemented with AJAX.
Although some REST APIs use SOAP protocols, REST and SOAP are entirely different approaches to building APIs. Interviewers may ask this to assess your depth of understanding.
Here are some of the differences between SOAP and REST.
SOAP:
REST:
HTTP response codes indicate the result of client requests.
Common HTTP status codes include:
Why: Avoid breaking clients as your API evolves.
Common strategies:
URI versioning: /v1/resources (simple, cache-friendly; leaks version into URLs).
Header-based: Accept: application/vnd.myapi+json; version=2 (clean URLs; harder to test in browser).
Query param: /resources?version=2 (easy; can be overused). Good practices: Semantic versions, deprecation headers/notices, sunset timelines, and clear changelogs.
Pagination patterns:
Limit/Offset: /items?limit=20&offset=40 (simple; can be slow for large offsets).
Cursor-based: /items?cursor=abc123&limit=20 (stable ordering, better performance at scale).
Filtering/Sorting: /items?status=active&created_after=2025-01-01&sort=-created_at,name
Metadata & links: Include total, has_next, and HATEOAS-style links: first, prev, next, last.
Consistency: Define allowed fields and operators; document defaults and max page size to prevent abuse.
Cache-Control: max-age, s-maxage, no-store, no-cache, stale-while-revalidate.
Validators:
ETag + If-None-Match → conditional GET/PUT; enables 304 Not Modified.
Last-Modified + If-Modified-Since.
Vary: Indicates which request headers affect the response (e.g., Vary: Accept-Encoding).
Design tips: Make GET responses cacheable by default, use strong ETags for exact byte equality, and invalidate on writes.
Transport: Always use HTTPS.
AuthN:
OAuth 2.0 (access tokens), OpenID Connect (identity), JWT bearer tokens, or simple API keys (lower security).
AuthZ: Scopes/roles/claims; enforce least privilege per endpoint.
Token handling: Short-lived access tokens, refresh tokens, rotation; store server-side secrets securely (KMS).
Security extras: CORS policies, CSRF protection for browser-based flows, rate limits, and audit logs.
Rate limiting: Fixed window, sliding window, token bucket, or leaky bucket; return headers like RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, and use 429 Too Many Requests with Retry-After.
Idempotency:
Methods: GET/PUT/DELETE are idempotent by spec; POST is not.
For POST where duplicates are harmful (e.g., payments), use Idempotency-Key header keyed by client-generated UUID; the server stores and replays the first result.
Backoff & retries: Recommend exponential backoff + jitter; document retry semantics per endpoint.
A consistent error-handling strategy makes your REST API more predictable and user-friendly.
Best practices:
Use proper HTTP status codes (e.g., 400 Bad Request, 404 Not Found, 500 Internal Server Error).
Return an error response body with helpful details:
{"error": "InvalidRequest","message": "Missing required field 'email'","timestamp": "2025-10-14T10:30:00Z","path": "/api/users"}
Include a unique error code for debugging.
Avoid exposing internal stack traces or database errors to clients.
Optionally, provide links to documentation in the error response (type or docs_url).
Security is one of the most important areas of REST API design. Interviewers may test your awareness of common threats.
Core best practices:
Enforce HTTPS for all requests.
Use authentication and authorization (e.g., OAuth 2.0, JWT).
Apply rate limiting and throttling to prevent abuse.
Validate and sanitize input parameters to avoid injection attacks.
Implement CORS correctly for browser-based clients.
Use API gateways or WAFs for additional protection.
Never expose sensitive details (tokens, keys, stack traces) in responses or logs.
Interviewers often look for how well you think about maintainability and collaboration.
Documentation:
Use OpenAPI (Swagger) to define endpoints, methods, parameters, and responses.
Host interactive documentation (e.g., Swagger UI, Redoc).
Keep docs versioned alongside your codebase.
Testing:
Write unit tests for individual endpoints and integration tests for workflows.
Use tools like Postman, cURL, or Insomnia for manual testing.
Automate API tests in CI/CD using frameworks like pytest, JUnit, or Newman.
Include contract tests to ensure compatibility across microservices.
Congratulations! You’re now prepared with some common REST API interview questions and answers. Where you go from here depends on your goals.
For interview prep, check out Interview Prep with Educative. Here, you’ll find all our resources for interview prep in one place, from tutorials and practice problems, to tips from industry experts.
To get hands-on with REST APIs, check out one of our interactive REST API courses:
Happy learning!
What is the REST API used for?
What are the features of RESTful Web Services?
