最初のAPI呼び出しを行う

You have read the docs; now you fire a real request. The goal of this lesson is one successful call that returns live data into your app.

We will pick a simple, free API, build the request, send it, and read the response, using your AI assistant to write and debug the code along the way.

For a first call, choose an API with no signup and a clear GET endpoint. Public services for jokes, quotes, or public weather are ideal practice grounds.

Starting simple removes auth and billing distractions so you can focus on the request and response flow itself.

A basic GET request needs just a URL and a method. Optional headers and query parameters refine it. Most first calls are a single line of code.

Ask your assistant to write that line in your language and explain each piece, so you understand what you are sending rather than copying blindly.

In JavaScript, fetch sends the request and returns a promise. You await the response, then call response.json() to get the parsed data.

This two-step pattern, fetch then parse, is the backbone of nearly every browser-based integration you will build with an assistant.

The parsed response is usually a JSON object. You reach into it by key, like data.results[0].name, to pull out the value you want.

If the structure confuses you, paste the actual response to your assistant and ask for the exact path to the field you need.

Query parameters go after a question mark in the URL, like ?city=Paris&units=metric. They filter or shape what the endpoint returns.

Build them carefully, since a typo means wrong or empty data. Your assistant can construct a parameterized URL from your inputs reliably.

Some endpoints need headers, such as Accept: application/json or a content type. Headers travel with the request as metadata, separate from the URL.

When docs mention a required header, ask your assistant to include it in the fetch options object so the call is accepted.

Before wiring data into your UI, log the response to the console. Seeing the raw object confirms the call worked and reveals the real field names.

This habit catches surprises early. Many integration bugs are simply a field named differently than the docs implied.

Once you have the data, the final step is rendering it. You assign the parsed value to a variable your view displays, like a text label or list item.

Describe the UI you want to your assistant along with the response shape, and let it generate the rendering code for your framework.

If your first call fails, check the status code and the URL spelling. A 404 means a wrong endpoint, a 401 means missing auth, a typo means empty data.

Paste the exact error and your code to your assistant. With both in hand it can usually pinpoint the fix in one reply.

A working first call is a milestone. The same pattern, build URL, fetch, parse, render, applies to almost every API you will ever touch.

Once one call works, swapping in a new endpoint is mostly changing the URL and the fields you read. The skill transfers directly.

You picked a simple API, built a request with optional parameters and headers, sent it with fetch, parsed the JSON, logged it, and rendered the result.

Failures are read from status codes and fixed with your assistant. Next, you will handle API keys safely and deal with errors gracefully.