Stop 23 · Interview PreparationTechnical · 6/8

REST APIs

Part of the Frontend Developer Roadmap

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`.

The jaadu carefully presses one big button once at a booking counter as a ticket slides out.

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

Client
API

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. 1

    Name the resources

    Nouns like /users, /posts, /posts/:id/comments.

  2. 2

    Map the actions

    Which method for read, create, update and delete.

  3. 3

    Shape the data

    Request and response bodies, including errors.

  4. 4

    Handle scale

    Pagination, filtering, caching headers and rate limits.

See it in code

Walk through the code

js
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

~30 min

Quick check

Which HTTP method is usually NOT idempotent?

Go deeper

  1. 1Be ready to design a simple REST API for a given resource on a whiteboard.
  2. 2Know the difference between PUT and PATCH, and why idempotency matters.
  3. 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.

Download
InsideEdge