In short
Calling fetch is easy. Interviews check whether you understand APIs as a contract: which method is safe to retry, how to paginate, and what to do when things fail.
Being fluent in discussing API design and consumption trade-offs — status codes, idempotency, versioning — beyond just knowing how to call `fetch`.

Think of it like this
The IRCTC booking counter
Checking seat availability ten times changes nothing. Pressing 'Book' twice could book two tickets. Good APIs are designed knowing which actions are safe to repeat and which are not.
Watch it happen
Which requests are safe to retry
PUT /users/7
1/6The client updates user 7 with a PUT.
The big ideas
What you need to know
Idempotent methods
Doing it once or five times has the same effect. GET, PUT and DELETE are idempotent. POST usually isn't.
PUT vs PATCH
PUT replaces the whole resource. PATCH changes only the fields you send.
Pagination
Offset (?page=2&limit=20) is simple. Cursor (?after=abc) holds up better when new data keeps arriving.
Versioning and errors
Version with /v1/ or headers, and return consistent error shapes so the frontend can show useful messages.
How it works
Talking through an API you'd design
- 1
Name the resources
Nouns like /users, /posts, /posts/:id/comments.
- 2
Map the actions
Which method for read, create, update and delete.
- 3
Shape the data
Request and response bodies, including errors.
- 4
Handle scale
Pagination, filtering, caching headers and rate limits.
See it in code
Walk through the code
1async function api(path, options = {}, retries = 2) {2 const method = options.method ?? "GET";3 const safeToRetry = ["GET", "PUT", "DELETE"].includes(method);4 5 const res = await fetch(`/api/v1${path}`, options);6 if (res.status >= 500 && safeToRetry && retries > 0) {7 return api(path, options, retries - 1);8 }9 if (!res.ok) {10 const body = await res.json().catch(() => ({}));11 throw new Error(body.message ?? `Request failed: ${res.status}`);12 }13 return res.status === 204 ? null : res.json();14}1/4Only idempotent methods are marked safe to retry.
Only idempotent methods are retried on server errors, so a flaky network can't place two orders. 204 No Content has no body, so it returns null.
Save yourself the pain
Common mistakes
Oops
Blindly retrying POST requests on failure.
Do this instead
A retried POST can create duplicates. Retry only idempotent methods, or have the server accept an idempotency key.
Oops
Saying 'REST just means JSON over HTTP'.
Do this instead
Explain resources in URLs, methods as actions, statelessness and status codes. That's what interviewers listen for.
Your mission
Design a mini API
Quick check
Which HTTP method is usually NOT idempotent?
Go deeper
- 1Be ready to design a simple REST API for a given resource on a whiteboard.
- 2Know the difference between PUT and PATCH, and why idempotency matters.
- 3Practice explaining how you'd handle API errors gracefully in a UI.
More technical at this stop
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.