Challenge 3: Library API or Web API? — Possible Solution
====================================================================

(a) Calling Array.map() in JavaScript
    -> LIBRARY API. map() is a function built into the JavaScript
       language itself, running entirely inside your own program.
       No request goes out anywhere; nothing on a network is involved.

(b) A weather app fetching a forecast from a remote server
    -> WEB API. This is exactly the client-server, network-based
       exchange this chapter is about — a request genuinely leaves
       the device and goes to a separate server somewhere else.

(c) Using Python's built-in len() function
    -> LIBRARY API. Same reasoning as (a) — len() runs locally,
       inside the same Python process that called it. There is no
       "other side" being contacted at all.

(d) A mobile game submitting a high score to a leaderboard server
    -> WEB API. The score has to travel from the player's device to
       a server that stores leaderboards for ALL players — that's a
       genuine network request to a separate system.

WHY THIS WORKS AS AN ANSWER
------------------------------
The test that separates the two categories is simple: does anything
leave the program and travel to a SEPARATE system over a network?
(a) and (c) are both "ask my own running program to do something it
already knows how to do" — no network round-trip, no separate server,
no possibility of the "call" failing because of a dropped internet
connection. (b) and (d) both involve reaching an entirely different
system that could be down, slow, or unreachable — which is precisely
the kind of failure mode a library API call doesn't have to worry
about, and a real difference in what each kind of "API" actually
means in practice, not just in name.