My progress
Menu

Level 3 · Programming Skills · Course 3.1 JavaScript Programming

Module 25: APIs and JSON

Goal: understand what an API is, read and write JSON, fetch data from real APIs, understand requests and responses, and handle keys, errors and limits safely. You'll build Project C, an API data viewer.

You'll need: your level-3 folder and Module 24.

Lessons

  1. 1What an API is15–25 minutes✓
  2. 2JSON15–25 minutes✓
  3. 3Fetching data15–25 minutes✓
  4. 4Requests and responses in detail15–25 minutes✓
  5. 5Keys, limits and safety15–25 minutes✓

🛠️Module practice: Project C, an API data viewer

Build viewer.js (in Node.js) or a page with viewer.html (in the browser) that:

  1. Takes a GitHub username (from the command line, process.argv[2], or a form field).
  2. Fetches the user and their public repositories (/users/NAME/repos).
  3. Shows name, number of repositories, and the five most recently updated repositories, sorted.
  4. Handles: a user that doesn't exist, no internet, and the rate limit (403 or 429), each with a clear message.
  5. Never uses innerHTML for data from the API.

Commit.

✅Module check

Explain in a few sentences, in your own words:

What happens when your app gets data from an API, and what can go wrong?

Show a good answer

A good answer mentions: the app sends an HTTP request (method, address, headers, maybe a JSON body) to an endpoint; the server replies with a status code and usually JSON, which is parsed. Things that go wrong: network failure, 4xx errors (bad request, not found, not allowed, rate limited), 5xx server errors, unexpected data, and CORS blocks in browsers. fetch doesn't fail on 4xx/5xx, so response.ok must be checked. API keys are secrets kept on the server, never in frontend code or Git.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. Your app's weather API suddenly breaks with no change on your side. What might have happened?

Why each option is right or wrong

  • “Your CSS stopped the data from showing” (Incorrect): CSS can hide things, but you said nothing changed on your side.
  • “JSON stopped being supported by the latest browser versions” (Incorrect): JSON support is built in and hasn't gone anywhere.
  • “Your browser's cache expired overnight” (Incorrect): An expired cache just fetches fresh data; it doesn't break an API.
  • “The API changed, went down, or your access changed” is correct.

    When you depend on someone else's API, their changes affect you. They might change the response format, have an outage, retire an old version, or change your plan's limits or key.

    • Check first: the provider's status page and your error responses.
    • Protect yourself: handle errors gracefully and read the provider's change notices.

📖 Revise: Lesson 1: What an API is

Question ID module-25-q1 · Report a mistake in this question
2. Is { name: 'Pen' } valid JSON?

Why each option is right or wrong

  • “Yes, because it's a valid JavaScript object, and JSON is JavaScript” (Incorrect): Valid JavaScript isn't automatically valid JSON; JSON is stricter.
  • “Yes, but only when it's parsed in Node.js” (Incorrect): JSON rules are the same everywhere.
  • “No, because JSON can't contain text values” (Incorrect): JSON holds text fine, in double quotes.
  • “No, JSON needs double quotes: { "name": "Pen" }” is correct.

    JSON looks like JavaScript but is stricter: keys must be in double quotes, and strings must use double quotes too. JavaScript accepts the first form as an object, but JSON.parse would reject it.

    • Also not allowed in JSON: trailing commas and comments.

📖 Revise: Lesson 2: JSON

Question ID module-25-q2 · Report a mistake in this question
3. How are dates usually sent in JSON?

Why each option is right or wrong

  • “As a special JSON date type” (Incorrect): JSON has only strings, numbers, booleans, null, arrays and objects.
  • “As text like "01/11/2026", in whatever local style the app uses” (Incorrect): Is that 1 November or 11 January? Local formats are ambiguous.
  • “They can't be sent in JSON at all” (Incorrect): They can, as strings.
  • “As text in ISO format, like "2026-11-01T09:30:00Z"” is correct.

    JSON has no date type. The common convention is an ISO 8601 string, which sorts correctly, includes the time zone, and every language can read it back.

    • Z means UTC. Convert to local time only when showing it.
    • Read it back: new Date(text).

📖 Revise: Lesson 2: JSON

Question ID module-25-q3 · Report a mistake in this question
4. A request returns 404, but your catch never runs. Why?

Why each option is right or wrong

  • “The server crashed before it could send back a proper error reply” (Incorrect): A 404 is a reply, so the server was working.
  • “catch only works with await, not fetch” (Incorrect): catch works with both; fetch just didn't reject.
  • “404 means the request was a success” (Incorrect): 404 means not found. fetch doesn't treat it as an error, but it is one for you.
  • “fetch only rejects on network failure; check response.ok yourself” is correct.

    To fetch, a 404 is a successful conversation: the server answered. It rejects only when no response arrives, like a network failure. Check response.ok (true for 200–299) and throw if it's false.

    • Pattern: if (!response.ok) throw new Error(response.status).

📖 Revise: Lesson 4: Requests and responses in detail

Question ID module-25-q4 · Report a mistake in this question
5. Why use encodeURIComponent on a search term?

Why each option is right or wrong

  • “To encrypt the search term so other people on the network can't read it” (Incorrect): Encoding isn't encryption; anyone can decode it. HTTPS protects it in transit.
  • “To shorten long search terms” (Incorrect): Encoding usually makes text longer.
  • “To translate the term into English” (Incorrect): It changes characters into codes, not languages.
  • “So spaces and special characters don't break the address” is correct.

    Characters like spaces, &, ? and # have special meanings in URLs. Encoding turns them into safe codes (a space becomes %20), so a search for 'pen & ink' arrives intact.

    • Even easier: URLSearchParams handles encoding for you.

📖 Revise: Lesson 3: Fetching data

Question ID module-25-q5 · Report a mistake in this question
6. An API returns 400. Whose problem is it usually?

Why each option is right or wrong

  • “The API server's, since it couldn't cope” (Incorrect): That would be a 5xx error.
  • “The internet provider's connection” (Incorrect): A 400 is a reply from the API, so the connection worked.
  • “The user's browser, which needs updating” (Incorrect): The request's content is the problem, not the browser.
  • “Yours: the data you sent was wrong” is correct.

    4xx codes mean the client's request had a problem: 400 Bad Request usually means missing fields or the wrong format. 5xx codes point to the server.

    • Read the response body: good APIs say which field was wrong.

📖 Revise: Lesson 4: Requests and responses in detail

Question ID module-25-q6 · Report a mistake in this question
7. You pushed an API key to GitHub, then deleted it in the next commit. Is it safe?

Why each option is right or wrong

  • “Yes, deleting it in a new commit removes it” (Incorrect): The old commit still contains it.
  • “Yes, as long as the repository is set to private on GitHub” (Incorrect): Private lowers the risk but doesn't remove it; anyone with access, or a future leak, can expose it.
  • “Yes, if nobody starred the repository” (Incorrect): Bots don't star repositories; they just scan them.
  • “No: it's still in history, so revoke it and create a new one” is correct.

    Git keeps every commit. Anyone who can see the repository can open the earlier commit and copy the key, and bots scan GitHub for keys within minutes.

    • Order: revoke the key at the provider first, then clean up.
    • Prevent: keep keys in .env, listed in .gitignore.

📖 Revise: Lesson 5: Keys, limits and safety

Question ID module-25-q7 · Report a mistake in this question
8. Your page's fetch to another site shows a CORS error. What's the usual fix?

Why each option is right or wrong

  • “Turn off the browser's security settings” (Incorrect): Your visitors won't do that, and it's unsafe.
  • “Switch from https to http in the address” (Incorrect): That makes it less secure and doesn't fix CORS.
  • “Retry the request a few times until the browser decides to allow it” (Incorrect): The block is a rule, not a temporary failure.
  • “Call that API from your own server, and fetch from your server” is correct.

    Browsers block pages from reading responses from other sites unless those sites allow it (CORS). You can't change their rules, but your server isn't a browser, so it can call the API and pass the data on.

    • If you own the API: add the right CORS headers there.

📖 Revise: Lesson 4: Requests and responses in detail

Question ID module-25-q8 · Report a mistake in this question
9. In the restaurant picture of an API, what's an endpoint?

Why each option is right or wrong

  • “The kitchen, where the food is actually prepared for the order” (Incorrect): That's the server behind the API.
  • “The waiter who carries your order” (Incorrect): That's the API itself, carrying requests and responses.
  • “The bill, which you get at the end” (Incorrect): The bill is closer to rate limits or pricing.
  • “One specific item you can order: an address you send a request to” is correct.

    If the API is the menu, each endpoint is one dish: a specific address like /weather/today that does one thing.

    • The waiter is the API carrying requests and responses; the kitchen is the server.

📖 Revise: Lesson 1: What an API is

Question ID module-25-q9 · Report a mistake in this question
10. Which method would an app usually use to cancel a booking?

Why each option is right or wrong

  • “GET, with the booking ID and the word cancel in the address” (Incorrect): GET must not change data; links and prefetching could cancel bookings by accident.
  • “HEAD, which checks the booking exists” (Incorrect): HEAD fetches headers only; it changes nothing.
  • “OPTIONS, which lists available actions” (Incorrect): OPTIONS asks what's allowed; it doesn't act.
  • “DELETE, or PATCH to set a cancelled status” is correct.

    DELETE removes a resource. Many apps keep cancelled bookings for records, so they use PATCH to change the status instead. Either way, it changes data, so it isn't GET.

    • GET should only read data, not change it.

📖 Revise: Lesson 4: Requests and responses in detail

Question ID module-25-q10 · Report a mistake in this question

ProLearners Assist