Lesson 1 of 30

APIs, REST & Data Binding

Q: Walk me through what actually happens, step by step, from a component calling fetch('/api/users') to that data appearing on screen.

A strong answer covers: fetch() resolves with a Response object, not the parsed data itself; You still need to call .json() (another promise) to get the parsed body; The resolved data is typically stored in state, which triggers a re-render that reads it — same mechanism as any other state update.

Q: A search-as-you-type input fires a fetch request on every keystroke. Sometimes the UI flashes an OLDER result after a NEWER one already rendered. What's happening, and how would you fix it?

A strong answer covers: Requests aren't guaranteed to resolve in the order they were sent — a slower earlier request can resolve after a faster later one; Fix: AbortController to cancel the previous in-flight request when a new one starts; Alternative fix: a monotonically increasing request id, ignoring any response that isn't the latest one sent.

How a frontend actually consumes an API — and how 'binding' data to the UI is just state driving a render, the same idea from the useState lesson.

14 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A search-as-you-type input fires a fetch on every keystroke. An older response sometimes overwrites a newer one already on screen. What actually causes this?

The browser only allows one fetch request to be in flight at a timefetch caches the first response and ignores all subsequent onesRequests can resolve out of order — a slower earlier request can finish after a faster later one

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on APIs, REST & Data Binding

What interviewers actually ask about this, and what a strong answer has to cover.

Walk me through what actually happens, step by step, from a component calling fetch('/api/users') to that data appearing on screen.

A strong answer covers

fetch() resolves with a Response object, not the parsed data itself
You still need to call .json() (another promise) to get the parsed body
The resolved data is typically stored in state, which triggers a re-render that reads it — same mechanism as any other state update

Likely follow-ups

What does res.ok actually check, and why isn't it enough on its own to assume the request truly succeeded?
If a user types quickly in a search box that fetches on every keystroke, what bug can happen with the order responses come back in, and how would you prevent it?
What's the actual difference between REST and 'an API that returns JSON'?

A search-as-you-type input fires a fetch request on every keystroke. Sometimes the UI flashes an OLDER result after a NEWER one already rendered. What's happening, and how would you fix it?

A strong answer covers

Requests aren't guaranteed to resolve in the order they were sent — a slower earlier request can resolve after a faster later one

The plain-language idea

A REST API is a set of URL endpoints a server exposes, organized around resources (/users, /users/42/posts) and standard HTTP verbs that say what to do with them: GET (read), POST (create), PUT/PATCH (update), DELETE (remove). REST is an architectural style, not a specific format — JSON is just the common choice for the data those endpoints send back.

"Binding" data to the UI isn't a separate mechanism you learn — it's the same idea as the useState lesson: fetched data becomes state, and state drives what renders. Nothing new, just a value that happened to come from a network call instead of a click.

See it in a real thing: fetch → state → render

function UserList() {
  const [users, setUsers] = useState([]);
  const [status, setStatus] = useState("loading"); // loading | ready | error

  useEffect(() => {
    fetch("/api/users")
      .then((res) => {
        if (!res.ok) throw new Error(`Server said ${res.status}`);
        return res.json();
      })
      .then((data) => {
        setUsers(data);
        setStatus("ready");
      })
      .catch(() => setStatus("error"));
  }, []);

  if (status === "loading") return <p>Loading…</p>;
  if (status === "error") return <p>Couldn't load users.</p>;
  return <ul>{users.map((u) => <li key={u.id}>{u.name}</li>)}</ul>;
}

fetch() resolves with a Response, not the data — you still have to call .json() (itself another promise) to get the parsed body. Once that data lands in setUsers, it's ordinary state; the "binding" is just the component re-rendering with it, same as any other state change.

REST: nouns in the URL, verbs in the methodStep 1 of 3

GET /users/42 — a URL identifies a resource (user 42), not an action.

What people usually miss

Watch out

REST isn't "an API that returns JSON." REST is specifically about resources, URLs, and HTTP verbs carrying meaning — an RPC-style API that happens to return JSON isn't automatically RESTful.
Status codes carry real information most candidates skip. 201 (created) vs 200 (ok) vs 204 (no content) vs 304 (not modified) vs 429 (rate limited) — each implies a different thing your code should do, not just "success or not."
Fast-typing search-as-you-type has a real race condition. If you fire a request on every keystroke, an earlier request can resolve after a later one — the UI can flash stale data over fresh data. Fix it with AbortController (cancel the previous request) or a request-id guard (ignore a response that isn't the latest one you sent).
Debouncing the input reduces the problem, but doesn't fully solve it. You can still fire two requests close together where the first is slower — you need to actually handle out-of-order responses, not just fire fewer requests.

Why this matters in interviews

"Fetch this list and show it" is a standard screening-round task, and what separates a strong answer isn't the happy path — it's whether you handle loading and error states, check the status code meaningfully, and know how to prevent stale responses from overwriting fresh ones.