Webbo3 Level 2 · JavaScript Development · Day 8 of 20

APIs and HTTP

How your JavaScript asks a computer in another country for data, and how to read what comes back.

An API is a door another company leaves open on purpose. Behind it is data you could never collect yourself: exchange rates, weather, football fixtures, a payment system, another team's database. Today you learn to knock on that door properly, and to understand the answer that comes back.

1. What an API actually is

You already know the restaurant. You sit at a table, the waiter takes your order to a kitchen you never see, and brings food back. The API is the waiter. It is an agreed list of things you are allowed to ask for and the shape of the answer you will get. You never see the kitchen, you do not need to, and that is the point: the other team can rebuild their entire kitchen and your order still works.

A web API is that idea over HTTP. You send a request to a URL, and a response comes back, almost always as JSON.

2. The parts of a request

3. Status codes

The families are the whole trick: 4xx means you got it wrong, 5xx means they did. That one sentence tells you who to go and talk to, and it will save you hours.

4. fetch, and the trap in it

const response = await fetch('https://api.example.com/students');
const students = await response.json();
console.log(students);

Two awaits, because there are two waits: one for the response to arrive, and one for the body to be read and parsed. Now the trap, and it catches everybody:

async function getStudents() {
  const response = await fetch('https://api.example.com/students');

  // fetch will NOT do this for you
  if (!response.ok) {
    throw new Error(`Request failed: ${response.status} ${response.statusText}`);
  }

  return response.json();
}

response.ok is simply true for any status in the 200s. Throwing when it is false is what puts a real HTTP error into the same catch block as a network failure, which is where you wanted it all along.

5. The complete pattern

This is the function you will copy into every project for the rest of the course. Read it slowly: every line is there because of something that goes wrong without it.

async function apiGet(url) {
  try {
    const response = await fetch(url, {
      headers: { 'Accept': 'application/json' }
    });

    if (!response.ok) {
      throw new Error(`${response.status} ${response.statusText}`);
    }

    return await response.json();

  } catch (error) {
    // A TypeError here almost always means the network, not your code
    if (error instanceof TypeError) {
      throw new Error('Could not reach the server. Check your connection.');
    }
    throw error;
  }
}

Sending data

async function createStudent(student) {
  const response = await fetch('https://api.example.com/students', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(student)            // an object will NOT do
  });

  if (!response.ok) throw new Error(`Failed: ${response.status}`);
  return response.json();
}

await createStudent({ name: 'Chidinma', city: 'Lagos' });

• body must be a string. Passing the object directly sends [object Object], and the server replies 400.
• Without Content-Type: application/json many servers will not parse the body and you get a 400 with an empty-looking payload.

6. JSON: the format in the middle

JSON looks like a JavaScript object and is not one. It is text. Two functions move between them, and they are the only two you need.

const student = { name: 'Chidinma', score: 88, tags: ['frontend'], active: true };

const asText = JSON.stringify(student);
console.log(typeof asText, asText);

const backToObject = JSON.parse(asText);
console.log(typeof backToObject, backToObject.name);

// readable version, for logging
console.log(JSON.stringify(student, null, 2));

const record = {
  name: 'Chidinma',
  joined: new Date('2026-09-12T08:00:00Z'),
  nickname: undefined,
  greet() { return 'hi'; }
};

console.log(JSON.parse(JSON.stringify(record)));

7. CORS: the error that is not your fault

You will meet this in your first hour with a real API, and without a name for it you will lose an afternoon.

Access to fetch at 'https://api.example.com/data' from origin
'http://localhost:5500' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

The browser refuses to let a page from one origin read a response from another origin unless the server sends a header saying it is allowed. Note what that means: the request usually went out and the server usually answered. The browser blocked you from reading the answer.

• It is a browser rule, not a JavaScript bug. The same request from a terminal or from a server works fine, which is why curl succeeds while your page fails.
• You cannot fix it from the frontend. No header you set, no option you pass to fetch, changes it.
• The fixes are real ones: use an API that permits browser requests, or put a small backend of your own in the middle, which is what you will do in Level 3.

8. API keys, and the mistake that costs money

Many APIs identify you with a key. Anything in your JavaScript is visible to anyone who opens DevTools, so a key in your frontend is a public key, whatever the documentation calls it.

• For this course, use APIs that need no key at all wherever you can.
• When a key is unavoidable, keep it in a .env file, add .env to .gitignore before your first commit, and commit a .env.example with the names and no values.
• A key that must stay secret has to live on a server, not in a browser. That is Level 3, and it is the honest answer.
• If you ever commit one: rotate it immediately. Deleting the commit does not help, because it is already in the history and probably already scraped.

# .gitignore  -  add this BEFORE your first commit
.env
node_modules/

Do this now

Use a public, keyless API. Good ones for today: https://restcountries.com/v3.1/all, https://api.github.com/users/<name>, or https://jsonplaceholder.typicode.com/posts.

1. Fetch a list and log it. Look at the real shape in the console before you write one line of rendering code.
2. Add the response.ok check and prove it works by requesting a URL you know is a 404. Confirm your catch runs.
3. Render the list onto the page with map and join, the Day 4 way.
4. Open the Network tab, refresh, and find your request. Read its status, its response headers and its JSON. This is where you will debug every API problem for the rest of your life.
5. Deliberately go offline and reload. What does your page do? Whatever it does now, make it say something useful.

Checkpoint

Tomorrow, Day 9: real data is messy, slow and sometimes empty. Searching, filtering and paging it without the interface lying to the user.