REST API Interview Questions

What should I focus on for a REST API interview?

Can I explain REST and choose the right HTTP method?

Start with resources, URLs, and HTTP methods. PUT versus PATCH was the most asked question, appearing in 23 of 377 interviews. Questions about choosing HTTP methods and defining REST were also among the most asked.

Reviews of real answers found gaps in these basics. Some answers missed that REST APIs expose resources through URLs and use HTTP methods to operate on them. Others missed parts of the core method set or when to use each method.

• Can you explain how resources, URLs, and methods fit together?
• Can you name GET, POST, PUT, PATCH, and DELETE, and say when to use each?
• Can you explain when you would choose PUT rather than PATCH?

Can I explain how an API connects to other systems?

Integration appeared in more interviews than any other topic: 99 of 377 interviews. Questions covered frontend connections, third-party services, SDKs, webhooks, messaging, streaming, and background workflows.

Can you explain how a frontend connects to an API? Can you describe a webhook flow? Check whether you can also explain how you would investigate a problem with a third-party integration, rather than only describe your own endpoint.

Can I explain my design, security, and performance choices?

These questions cover how you define an API, protect it, and handle large datasets or high traffic. Use these checks to find what you need to review:

• Can you name resources and endpoints, document an API contract with OpenAPI, and keep changes backward compatible?
• Can you explain how you would handle filtering, pagination, caching, and rate limiting?
• Can you describe how you would use authentication, authorization, and access controls to protect sensitive data?

Can I handle repeated requests and failures?

Reliability appeared in 64 of 377 interviews. Questions covered duplicate prevention, concurrency, timeouts, payment failures, and consistency across systems.

Can you explain idempotency and why it is useful? Then go further: where would you store an idempotency key, and what would you return for a repeated request? Can you explain how you would retry after a timeout without creating duplicate operations?

Can I build a small endpoint?

Coding tasks appeared in 9 of 377 interviews. Tasks included creating and retrieving a user, updating a user by ID, and creating an order.

Can you write a user endpoint, store the user in memory or a database, retrieve it, and return appropriate HTTP status codes? Can you also show the route and controller action for an update by ID?

Who gets asked REST API

The 20 most asked REST API questions

Counted by interview, not by mention: a question asked twice in one conversation counts once.

1. What is the difference between PUT and PATCH, and when would you use each?

   Asked in 23 of 377 interviews · last asked Oct 23 · Concept · Junior

   Show answer

   PUT replaces a resource’s full representation; PATCH applies changes to it. Use PUT when sending a complete replacement, and PATCH when updating only part of the resource. PUT is idempotent: repeating the same request has the same intended effect. PATCH may be idempotent, depending on the changes requested.

   • PUT can also create a resource at the target URL if the API allows it.
   • Do not assume PUT preserves fields left out of the request.
   • PATCH behavior depends on the patch format and the API contract.

   What the interviewer checks: The interviewer checks whether you understand replacement versus partial updates and how repeated requests affect the resource.

   Other ways it was asked

   • “What is the difference between PUT and PATCH?”
   • “What is the difference between the PUT and PATCH methods?”
   • “What is the difference between the HTTP POST and PUT methods?”

2. What HTTP methods are used in REST APIs, and when should you use each?

   Asked in 20 of 377 interviews · last asked Oct 23 · Concept · Junior

   Show answer

   Use GET to read a resource and POST to submit data, often to create a resource. Use PUT to create or replace a resource at a known URL, and PATCH for partial updates. Use DELETE to remove a resource. HEAD returns headers without a body; OPTIONS describes communication options and supports CORS preflight.

   • GET, HEAD, and OPTIONS are safe: they should not request changes to server state.
   • PUT generally replaces the full resource representation; PATCH applies partial changes.
   • PUT and DELETE are idempotent: repeating the request has the same intended effect, though responses may differ.
   • POST and PATCH are not guaranteed to be idempotent.

   What the interviewer checks: The interviewer checks whether you can choose the right method and explain its update and retry behavior.

   Common mistake (in 3 of 9 reviewed answers): Many answers forget that the core set includes GET, POST, PUT, PATCH, and DELETE, so explain each one.

   Other ways it was asked

   • “What are the standard HTTP methods used in a REST API?”
   • “Which HTTP methods are used to interact with APIs, and when would you use them?”
   • “What are the common HTTP methods?”

3. What is a REST API?

   Asked in 16 of 377 interviews · last asked Oct 5 · Concept · Junior

   Show answer

   A REST API is an interface that follows REST design rules. It exposes resources, such as users or orders, through URLs and uses HTTP methods to work with them. Each request contains the information needed to handle it, without relying on stored client session state.

   • Use resource URLs, such as /users/42, with methods like GET, POST, PUT, and DELETE.
   • Requests are stateless; the server can still store resource data.
   • Use HTTP status codes to show results, such as 200, 201, or 404.
   • JSON is common, but REST does not require it.

   CodeCopy

   GET /users/42
   
   200 OK
   Content-Type: application/json
   
   {"id":42,"name":"Sam"}

   What the interviewer checks: The interviewer checks whether you understand resources, HTTP methods, and stateless requests.

   Common mistake (in 5 of 8 reviewed answers): Many answers forget that REST APIs expose resources through URLs and use HTTP methods to work with them.

   Other ways it was asked

   • “What are REST APIs?”
   • “What do you mean by a RESTful API?”
   • “What is the REST API?”

4. How do you approach REST API design, and what considerations and tools guide you?

   Asked in 11 of 377 interviews · last asked Oct 16 · Concept · Mid-level

   Show answer

   I start with client needs and model resources with clear URLs, HTTP methods, and status codes. I define request and response formats in OpenAPI and review the contract before coding. I plan security, validation, errors, pagination, and compatibility. I use Swagger UI for documentation, Postman or curl for exploration, and automated tests to check behavior.

   • Keep requests stateless, and use HTTP methods according to their meaning.
   • Use HTTPS, authenticate callers, and check permissions for each resource.
   • Keep errors consistent; define pagination, filtering, and rate limits where needed.
   • Avoid breaking clients; plan retries, idempotency, and caching where appropriate.

   What the interviewer checks: The interviewer checks whether you can turn client needs into a secure, consistent API that is easy to use and maintain.

   Other ways it was asked

   • “How do you design and develop a RESTful API?”
   • “What factors do you consider when designing or consuming REST APIs?”
   • “What do you consider when designing a REST API?”

5. What does idempotency mean in HTTP APIs, and why is it useful?

   Asked in 10 of 377 interviews · last asked Oct 16 · Concept · Mid-level

   Show answer

   Idempotency means repeating the same request has the same intended effect on the server as sending it once. It makes retries safer when a timeout leaves the client unsure whether a request succeeded. Retrying an idempotent request does not repeat its intended change.

   • GET, HEAD, OPTIONS, TRACE, PUT, and DELETE are idempotent by HTTP semantics.
   • Responses may differ: a repeated DELETE can return 404 after the first request succeeds.
   • POST and PATCH are not guaranteed to be idempotent.
   • An API can support idempotency keys to prevent duplicate actions, such as payments, when retrying POST requests.

   What the interviewer checks: The interviewer checks whether you understand safe retries and the difference between repeated effects and repeated responses.

   Other ways it was asked

   • “What does idempotency mean?”
   • “Which HTTP methods are idempotent?”
   • “What is idempotency?”

6. What is the difference between GET and POST?

   Asked in 9 of 377 interviews · last asked Aug 20 · Concept · Junior

   Show answer

   GET retrieves data from a server. POST submits data for processing, often to create a resource or trigger an action. GET is safe and idempotent: it should not request state changes, and repeating it has the same intended effect. POST is not guaranteed to be idempotent, so repeating it may create duplicates.

   • HTML forms put GET data in the URL and POST data in the request body.
   • GET responses can be cached; POST responses are cacheable only under specific conditions.
   • POST is not automatically secure because it uses a body; both methods need HTTPS to protect data.

   What the interviewer checks: The interviewer checks whether you understand each method’s purpose, safety, and behavior when requests are repeated.

   Other ways it was asked

   • “What is the difference between the GET and POST methods in an API?”
   • “What is the difference between the GET and POST methods in an HTML form?”
   • “What is the difference between GET and POST methods in PHP?”

7. How is GraphQL different from REST?

   Asked in 7 of 377 interviews · last asked Oct 22 · Concept · Mid-level

   Show answer

   GraphQL is a query language for APIs, while REST is an architectural style. GraphQL lets clients request specific fields and related data, usually through one endpoint. REST APIs usually expose resources through separate URLs and use HTTP methods such as GET and POST. GraphQL can reduce unwanted data and extra requests, but adds query processing complexity.

   • GraphQL defines a typed schema that clients can query.
   • REST APIs can also support field selection and related data; these features are not unique to GraphQL.
   • REST GET responses fit standard HTTP caching more naturally; GraphQL caching often needs extra tooling.
   • GraphQL servers need controls to limit expensive or deeply nested queries.

   What the interviewer checks: The interviewer is checking whether you understand client-driven queries, resource-based APIs, and their trade-offs.

   Other ways it was asked

   • “What are the differences between GraphQL and REST?”
   • “What problem does GraphQL solve compared with REST APIs?”
   • “What is the difference between GraphQL and REST?”

8. What techniques and tools would you use to secure a REST API?

   Asked in 6 of 377 interviews · last asked Oct 13 · Scenario · Senior

   Show answer

   I would use HTTPS, verify client identity, and check permissions on every request and resource. For user login, I would use OpenID Connect; for delegated access, OAuth 2.0 access tokens. I would also validate input, use parameterized database queries, limit request rates, protect secrets, and monitor security events.

   • Validate JWT signatures, issuer, audience, and expiry; a valid token does not grant access to every resource.
   • Use an API gateway for rate limits and request size limits, not as a replacement for application authorization.
   • Store credentials in a secrets manager, rotate them, and never log tokens or passwords.
   • Keep dependencies patched and use security scanners; CORS is a browser control, not API access protection.

   What the interviewer checks: The interviewer checks whether you can combine identity checks, resource permissions, input protection, and operational safeguards.

   Other ways it was asked

   • “How do you secure a REST API?”
   • “How do you secure a web API?”
   • “How do you secure an API?”

9. How would you design rate limiting for a public API?

   Asked in 6 of 377 interviews · last asked Oct 16 · Design · Senior

   Show answer

   I would limit requests per API key or user at the API gateway, with IP limits for anonymous traffic. A token bucket allows short bursts while limiting the average rate. Across servers, I would keep shared state in Redis and update it atomically. Rejected requests get HTTP 429 with Retry-After.

   • Set limits by customer plan and endpoint cost.
   • Use atomic updates so concurrent requests cannot bypass the limit.
   • IP limits can affect unrelated users sharing one network.
   • Decide whether to allow or block requests if the rate limiter fails.

   What the interviewer checks: The interviewer checks whether you can enforce fair limits across servers while handling bursts and failures.

   Other ways it was asked

   • “How would you implement a rate limiter for APIs?”
   • “What is API rate limiting, and how would you implement it?”
   • “Imagine you're building an API in Node.js that needs to handle rate limiting for different users. How would you design that solution?”

10. How would you make an API operation idempotent, including key storage and responses to repeated requests?

    Asked in 6 of 377 interviews · last asked Oct 21 · Design · Senior

    Show answer

    I would use a client-generated idempotency key so retries apply the operation only once. I would atomically reserve it in shared, durable storage, scoped to the authenticated user and operation. I would store the request fingerprint, state, and final response. Completed matching retries get the saved status and body; changed input gets a conflict.

    • Enforce uniqueness on user, operation, and key; clients must reuse the key when retrying.
    • For an in-progress request, wait or return a documented retryable response; never start duplicate work.
    • Commit database changes and the saved response together; pass a stable key to external payment providers.
    • Keep records for a documented retry window; after expiry, the same key may trigger another operation.

    What the interviewer checks: The interviewer checks whether retries, concurrent requests, and crashes can happen without causing duplicate effects.

    Other ways it was asked

    • “How would you implement idempotency for a charge-customer call? What idempotency key strategy would you use, where would you persist it, and what would you return for a repeated request?”
    • “How would you implement idempotency end to end? Where would you store the idempotency key, how would you validate it per user, and what would you return for a repeated request?”
    • “In the same create endpoint, how do you handle idempotency, especially for retries, so you don't accidentally create duplicate resources?”

11. What are webhooks, and when would you use them instead of REST API calls?

    Asked in 6 of 377 interviews · last asked Oct 13 · Concept · Junior

    Show answer

    A webhook is an HTTP request a service sends to your endpoint when an event happens. Use webhooks for event updates, such as payment confirmations, instead of repeatedly polling a REST API. Use REST API calls when you need to fetch data or request an action; both can work together.

    • Webhooks push event updates; polling repeatedly checks for changes.
    • Use HTTPS, verify signatures when supported, and check signed timestamps when available to help prevent replay attacks.
    • Acknowledge valid events quickly, then process longer tasks in the background.
    • Handle duplicate deliveries safely; retry and delivery guarantees depend on the provider.

    What the interviewer checks: The interviewer checks whether you understand event-driven updates, when polling is needed, and secure, reliable webhook handling.

    Other ways it was asked

    • “What is a webhook, and how do you secure one?”
    • “What is a webhook? Explain it.”
    • “What do you mean by webhook?”

12. What is the difference between SOAP and REST?

    Asked in 5 of 377 interviews · last asked Oct 15 · Concept · Junior

    Show answer

    SOAP is a messaging protocol, while REST is an architectural style. SOAP uses XML messages; REST APIs can use JSON, XML, or other formats. REST is often a good fit for web and mobile APIs. Choose SOAP when you need an existing SOAP contract or standards such as WS-Security.

    • SOAP can use HTTP or other transports; REST APIs commonly use HTTP methods and status codes.
    • REST defines constraints such as stateless requests and a uniform interface.
    • SOAP services often use WSDL contracts; REST does not require a specific contract format.
    • Both can be secure; SOAP adds standards for message-level security.

    What the interviewer checks: The interviewer checks whether you distinguish a protocol from an architectural style and explain when each fits.

    Other ways it was asked

    • “What is the difference between REST and SOAP?”
    • “How do SOAP and REST differ, and in what situations would you choose each?”
    • “What is the difference between REST and SOAP API?”

13. What is an API?

    Asked in 5 of 377 interviews · last asked Sep 30 · Concept · Junior

    Show answer

    An API, or Application Programming Interface, is a set of rules that lets software systems communicate. It defines what one system can request from another and how the result is returned. APIs let developers use features or data without knowing how the other system works inside.

    • An API defines how software can interact.
    • It helps systems share data and reuse features.
    • APIs are not limited to the web; REST APIs are one kind.

    What the interviewer checks: The interviewer wants to know whether you understand what an API does and why software uses it.

    Other ways it was asked

    • “What is an API, and why is it important?”
    • “Can you explain what an API is?”

14. What do HTTP 401 and 403 mean, and how do you troubleshoot each?

    Asked in 5 of 377 interviews · last asked Oct 13 · Concept · Junior

    Show answer

    HTTP 401 means the request lacks valid authentication credentials. HTTP 403 means the server understood the request but refuses access, often because permissions are missing. For 401, check the Authorization header, token validity, and authentication scheme. For 403, check roles, scopes, resource permissions, and access policies.

    • A 401 response must include a WWW-Authenticate header describing an authentication challenge.
    • For 401, check whether credentials are missing, expired, revoked, or invalid.
    • A 403 does not always mean the user is authenticated; other access policies can block requests.
    • Retrying a 403 with the same credentials usually will not help.

    What the interviewer checks: The interviewer checks whether you distinguish authentication from access restrictions and can troubleshoot both.

    Other ways it was asked

    • “What do HTTP status codes 401 and 403 mean, and when would you use each?”
    • “What is the difference between HTTP status codes 401 and 403?”
    • “What HTTP status codes indicate authentication and authorization failures?”

15. How do you change an API without breaking existing clients?

    Asked in 4 of 377 interviews · last asked Oct 23 · Scenario · Mid-level

    Show answer

    I keep changes backward compatible whenever possible, so existing clients can still use the API unchanged. For breaking changes, I introduce a new version and keep the old version running during migration. I test compatibility, document the changes, and give clients time to move before retiring the old version.

    • Avoid removing fields, changing types, or making optional inputs required in an existing version.
    • Additive changes are usually safer, but strict clients may reject new fields or enum values.
    • Expose versions consistently, such as through URL paths or request headers.
    • Announce retirement dates and track old-version usage before shutting it down.

    What the interviewer checks: The interviewer checks whether you can preserve existing client behavior while planning and managing breaking changes.

    Other ways it was asked

    • “How do you handle API versioning?”
    • “How do you ensure your API versioning doesn't disrupt existing clients, especially when making significant updates?”
    • “How do you version your API?”

16. How do you authenticate an API?

    Asked in 4 of 377 interviews · last asked Sep 19 · Concept · Junior

    Show answer

    I authenticate API requests by checking credentials, such as an API key or access token, over HTTPS. For user access, I can use OpenID Connect for login and OAuth 2.0 access tokens for API calls. After validating the credentials, I check permissions separately.

    • API keys usually identify applications, not individual users.
    • For JWT access tokens, validate the signature, issuer, audience, and expiry.
    • Return 401 for missing or invalid credentials; return 403 when valid credentials lack permission.
    • Authentication checks identity. Authorization checks what that identity can do.

    What the interviewer checks: The interviewer checks whether you can choose suitable credentials, validate them safely, and separate authentication from authorization.

    Other ways it was asked

    • “How would you implement authentication for an API?”
    • “How does authentication work in an API?”
    • “What authentication methods are commonly used in APIs?”

17. How do offset pagination and cursor pagination differ?

    Asked in 4 of 377 interviews · last asked Oct 14 · Concept · Mid-level

    Show answer

    Offset pagination skips a set number of rows, then returns a page. Cursor pagination uses a token to continue from a known position in the result order. Offset makes page jumps easy but can slow down at large offsets. Cursor pagination is usually faster for deep pages, but arbitrary page jumps are harder.

    • Both need a stable sort order, with a unique field to break ties.
    • Inserts or deletes can make offset pagination skip or repeat items between requests.
    • Position-based cursors handle those shifts better, but do not guarantee an unchanged view of the data.
    • Efficient cursor queries need indexes that support the sort order.

    What the interviewer checks: The interviewer checks whether you understand navigation, performance, and what happens when data changes between requests.

    Other ways it was asked

    • “What is the difference between using an offset and a cursor for database pagination?”
    • “Explain the trade-offs between offset pagination and cursor pagination.”
    • “What is the difference between page-based pagination and cursor-based pagination?”

18. What is JSON?

    Asked in 3 of 377 interviews · last asked Aug 27 · Concept · Junior

    Show answer

    JSON stands for JavaScript Object Notation. It is a text format used to exchange data, often between a REST API and a client. It supports objects, arrays, strings, numbers, booleans, and null. Despite its name, it works with many programming languages.

    • Objects contain key-value pairs; arrays contain ordered values.
    • Object keys and strings must use double quotes.
    • Standard JSON does not allow comments or trailing commas.

    CodeCopy

    {
      "id": 42,
      "name": "Sam",
      "active": true,
      "roles": ["reader"]
    }

    What the interviewer checks: The interviewer checks whether you understand JSON’s purpose, basic structure, and syntax.

    Other ways it was asked

    • “Can you tell me about JSON?”

19. What are the different types of API calls?

    Asked in 3 of 377 interviews · last asked Oct 3 · Concept · Junior

    Show answer

    REST API calls are usually grouped by HTTP method. GET reads data, POST submits data or creates a resource, PUT replaces or creates a resource at a known URL, PATCH partially updates a resource, and DELETE removes it. HEAD returns headers without a response body; OPTIONS reports supported communication options.

    • GET and HEAD should not request changes to server data.
    • PUT and DELETE are idempotent: repeating the same request has the same intended effect.
    • POST and PATCH are not guaranteed to be idempotent.

    What the interviewer checks: The interviewer checks whether you can choose the right HTTP method and understand its expected behavior.

    Other ways it was asked

    • “What are the different types of APIs?”
    • “What types of API requests are there?”

20. How would you implement API versioning, and what would versioned endpoints look like?

    Asked in 3 of 377 interviews · last asked Oct 16 · Scenario · Mid-level

    Show answer

    I would put the major API version in the URL, such as `/api/v1/orders`, and route each version to its own handlers. I would add a new version for breaking changes and keep compatible changes in the current version. Old versions would stay available during a documented migration period.

    • URL paths are easy to see and test; headers or media types are alternatives.
    • Version both request and response contracts, not just endpoint names.
    • Test supported versions and announce retirement dates before removing old ones.

    CodeCopy

    GET /api/v1/orders/123
    POST /api/v1/orders
    GET /api/v2/orders/123
    POST /api/v2/orders

    What the interviewer checks: The interviewer is checking whether you can evolve an API without unexpectedly breaking existing clients.

    Other ways it was asked

    • “What steps would you follow to version an API?”
    • “How can you implement versioning in a Web API?”
    • “How can you implement API versioning, and what would a versioned GET or POST method look like?”

Related interview questions

• Software Engineer interview questions
• AI Engineer interview questions
• QA Engineer interview questions
• Solutions Architect interview questions
• Data Structures and Algorithms interview questions
• OOP and Design Patterns interview questions
• System Design interview questions
• Microservices interview questions
• Kafka and Message Queues interview questions
• Caching and Redis interview questions
• Operating Systems interview questions
• Computer Networks interview questions
• Git interview questions

How this list is made

Every question here was asked by a real interviewer in a real job interview that a candidate ran MeetAssist in. After the call, the interviewer's questions are pulled from the transcript. Practice sessions, tests, exams and anything that was not a job interview are dropped.

Questions are rewritten so they make sense on their own: names of people, employers and clients are removed, and speech-to-text mistakes are fixed. Small talk, logistics and questions about one candidate's own résumé are left out. Rephrasings of the same question are merged, and the count is the number of different interviews it came up in.

The interviews come from candidates who use MeetAssist, so they lean towards software, data and AI roles: the shares describe these interviews, not every REST API interview. Answers to the most asked questions are written and checked by an editor; a "common mistake" is shown only when reviews of real answers in these interviews show it, with the count.

377 interviews, 243 candidates, Jan 2026 to Oct 2026. Updated every month with new interviews.