Challenge 2: Spot the API in Everyday Life — Possible Solution
====================================================================

EXAMPLE ANSWER (a map app searching for a restaurant)
------------------------------------------------------
App/website chosen: A maps app searching for "coffee shops near me."

The moment: When you type a search and the list of nearby coffee
shops appears, the app almost certainly isn't storing every coffee
shop in the world on your phone already — it's sending a web API
request out to a server the moment you search.

What the request might ask for (in plain words):
  "Find coffee shops within 2km of this latitude/longitude,
   sorted by distance, and tell me their name, address, and
   whether they're currently open."

What the response might contain (in plain words):
  A list of matching coffee shops, each with a name, an address,
  a distance from you, an open/closed status, and maybe a rating —
  structured data the app can then render as pins on a map and
  rows in a list, rather than a ready-made web page.

WHY THIS WORKS AS AN ANSWER
------------------------------
The key insight this challenge is testing is recognizing that an API
call is usually INVISIBLE to the end user — there's no button labeled
"call the API," it's just the app fetching data it doesn't already
have stored locally. Any answer works as long as it:
  1. Picks a moment where fresh, changeable data appears (search
     results, live status, prices, a feed updating) rather than
     something that's clearly just stored on the device already
     (like a static settings screen).
  2. Describes the request in terms of WHAT is being asked for, not
     HOW (no syntax needed yet — that's Chapter 2's job).
  3. Describes the response as structured data the app can use to
     build its own display, not as a ready-made web page.