JavaScript | 非同期処理：fetch / API 通信 – GET リクエスト

JavaScript JavaScript
スポンサーリンク

GET リクエストって何をしているのか

まず「GET リクエスト」とは、
“サーバーにデータをください、とお願いするためのリクエスト” です。

  • 今日の天気を教えて
  • ユーザー一覧をちょうだい
  • 記事の詳細を見せて

みたいな「情報を取得する」目的で使う HTTP メソッドが GET。
JavaScript の世界では、これを fetch を使って行います。

ここが重要です。
GET リクエストは「何かを変える」のではなく「情報を取りにいく」もの。
データの追加・更新・削除ではなく、「読み取り専用」のつもりで使うのが基本です。

fetch で GET リクエストを送る基本形

一番シンプルな GET の書き方

fetch に URL だけ渡すと、それは「GET リクエスト」になります。

const response = await fetch("https://example.com/api/users");
JavaScript

この一行で、

「https://example.com/api/users に、GET リクエストを飛ばしてきて」とブラウザに指示しています。

fetch は非同期なので、普通は async / await とセットで使います。

async function loadUsers() {
  const response = await fetch("https://example.com/api/users");
}
JavaScript

ここで返ってくる response は「レスポンス全体」です。
まだ JSON の中身そのものではありません。

JSON を取り出すまでの 2 段階

GET で JSON をもらう基本パターンは、ほぼこの形に落ち着きます。

async function loadUsers() {
  const response = await fetch("https://example.com/api/users");

  const data = await response.json();

  console.log(data);
}
JavaScript

1 行ずつ噛み砕きます。

1 行目の fetch(...) で、「サーバーにデータください」とリクエストを送る
それを await して、レスポンス（Response オブジェクト）を response に受け取る。

2 行目の response.json() で、「レスポンスボディを JSON として解釈してね」とお願いする
これも非同期なので await して、やっと data に「普通の JS オブジェクト」としてデータが入る。

3 行目以降で、その data を好きに使う（表示したり、画面に出したり）。

ここが重要です。
GET のときでも、「fetch → Response → JSON の中身」という 2 段階構造 になっていることを、しっかり意識してください。
fetch の戻り値が、いきなり JSON ではない点が最初のつまずきポイントです。

HTTP エラーをちゃんと見る：response.ok と status

fetch は「404 でも 500 でも」一応成功扱いになる

ここは初心者が 99% 引っかかるポイントです。

const response = await fetch("https://example.com/api/users");
JavaScript

この fetch は、

  • サーバーが 404（見つからない）を返しても
  • 500（サーバーエラー）を返しても

基本的には「Promise を resolve して response を返してしまう」性質があります。

つまり、HTTP 的に失敗していても、JavaScript 的には「一旦成功しました」と扱われる のです。

本当にエラーで reject されるのは、

  • ネットワークが完全に繋がらない
  • CORS などでブラウザがブロックした

など、「通信そのものが成り立たない」ような場合です。

だから自分で ok / status をチェックする必要がある

GET リクエストで安全に処理するなら、こういう形が「ちゃんとした版」です。

async function loadUsers() {
  try {
    const response = await fetch("https://example.com/api/users");

    if (!response.ok) {
      throw new Error("HTTPエラー: " + response.status);
    }

    const data = await response.json();
    console.log("ユーザー一覧:", data);
  } catch (err) {
    console.error("通信に失敗しました:", err);
  }
}
JavaScript

response.ok は、ステータスコードが 200〜299 のときに true になる便利フラグです。
200〜299 は「成功系」の範囲なので、「サーバーもちゃんと OK 返してる？」をチェックするときに使えます。

response.status は、数字のステータスコード（200, 404, 500 など）が入っています。

if (!response.ok) { throw ... } としておけば、
HTTP 的にエラーのときに自分で例外を投げて、下の json() には進まず、catch に飛ばせます。

ここが重要です。
GET リクエストを書くときは「fetch が成功したか？」だけではなく、「サーバーが成功ステータスを返したか？」も必ず見ること。
response.ok はそのための入口で、エラーなら例外を投げて catch でまとめて扱う、という型を体に染み込ませてください。

クエリパラメータ付きの GET（?page=1 のようなやつ）

URL にパラメータを付けて条件を指定する

GET リクエストでは、よく「クエリパラメータ」と呼ばれる追加情報を URL のあとに付けます。

例えば、

https://example.com/api/users?page=2&limit=10

これは、「2 ページ目を 10 件ずつでください」のような意味かもしれません。

JavaScript から書くときも、基本は「文字列として URL を組み立てる」だけです。

const page = 2;
const limit = 10;

const url = `https://example.com/api/users?page=${page}&limit=${limit}`;

const response = await fetch(url);
JavaScript

URLSearchParams を使って少し綺麗に書く

パラメータが増えてくると、手書きで ? や & をつなぐのがつらくなります。
そのときによく使うのが URLSearchParams です。

const params = new URLSearchParams({
  page: 2,
  limit: 10,
  keyword: "taro",
});

const url = "https://example.com/api/users?" + params.toString();

const response = await fetch(url);
JavaScript

URLSearchParams は、オブジェクトから page=2&limit=10&keyword=taro のような文字列を作ってくれます。

ここが重要です。
GET リクエストで「条件付きでデータを取る」ときは、クエリパラメータで条件を表現するのが基本 です。
JavaScript からは「URL を文字列として組み立てる」だけですが、パラメータが増えたら URLSearchParams を使うと心が平和になります。

then / catch で書く GET（Promise チェーン）

async / await の裏側で何が起きているか

同じ GET 処理を、あえて then / catch で書いてみるとこうなります。

fetch("https://example.com/api/users")
  .then((response) => {
    if (!response.ok) {
      throw new Error("HTTPエラー: " + response.status);
    }
    return response.json();
  })
  .then((data) => {
    console.log("ユーザー一覧:", data);
  })
  .catch((err) => {
    console.error("通信に失敗しました:", err);
  });
JavaScript

1 つ目の then で response を受け取り、ok をチェックしてダメなら throw。
OK なら response.json() を return して、2 つ目の then に data が渡されます。

どこかで throw されたり、fetch が失敗したりすると、最後の catch に飛びます。

async / await 版と対応させてみると、やっていることは同じなのが分かると思います。

ここが重要です。
GET リクエストを async / await で理解しておけば、
then / catch のコードを見ても「これは fetch → ok チェック → json → 使用 → エラーハンドリングだな」と読み解ける ようになります。
まずは async / await を軸に覚えておくと良いです。

実務で必ず出会う壁：CORS とブラウザの制限

コードは合っているのにエラーが出る…の典型

GET を練習していると、こんなエラーに出会うことがあります。

「CORS policy により云々…」のようなメッセージです。

これは、ブラウザのセキュリティ機能（CORS）が、
「この JavaScript から、そのサーバーへのアクセスを許していないよ」と言っている 状態です。

この場合、

  • fetch の書き方をいじっても直らない
  • サーバー側が「このオリジン（ドメイン）からのアクセスを許可しますよ」と設定してくれないと解決しない

という性質があります。

「自分のせいか、サーバーの制限か」を分けて考える

コードを書いていて GET が失敗したとき、
まずはこの 2 つを切り分けることが大切です。

URL がそもそも間違っている、サーバーが 404/500 を返している
→ 自分の側（URL・エンドポイントの間違い）の可能性が高い。

CORS エラーが出ている
→ サーバー側の設定（Access-Control-Allow-Origin など）の問題なので、フロント側の JavaScript で直せない。

ここが重要です。
GET リクエストが失敗しても、それが「fetch の書き方のせい」とは限りません。
「自分のバグ」と「サーバー・CORS 側の事情」を分けて理解できると、デバッグで無駄にハマらなくなります。

初心者として「GET リクエスト」で本当に押さえてほしいこと

GET は「サーバーから情報を取得する」ためのリクエストで、fetch(url) と書けば基本的に GET になる。
戻ってくるのは JSON ではなく Response オブジェクトなので、response.json() で中身を取り出す 2 段階がある。

response.ok / response.status を使って、「サーバーが本当に成功を返しているか」を自分で確認する。
エラーなら例外を投げて catch でまとめて扱う形を覚えると、GET のエラーハンドリングが安定する。

条件付き GET（検索やページング）は、クエリパラメータ（?page=2&limit=10 など）を使う。
パラメータが増えてきたら URLSearchParams で文字列を組み立てるとスッキリ書ける。

async / await 版で書ければ、then / catch 版の Promise チェーンも理解できる。
どちらも「fetch → ok チェック → json → データを使う → エラー処理」という流れは同じ。

ここが重要です。
GET リクエストは、フロントエンドとバックエンドが最初に「握手」する場所です。
コードを書くときには、
「サーバーに何をお願いしているのか？」
「サーバーからどんな形で返してもらいたいのか？」
「失敗したらどう振る舞うべきか？」
を日本語で説明できる状態を目指してください。
そのうえで fetch → response → json → 使用 のパターンを繰り返し書いていくと、非同期の GET 通信は自然と怖くなくなっていきます。

もし練習するなら、例えばこういうことをやってみてください。

  • ダミーの URL でもいいので、fetch → ok チェック → json → console.log の形を何度か書いてみる。
  • クエリパラメータ付きの URL を自分で文字列連結してみて、その後 URLSearchParams 版にも書き換えて、どちらが読みやすいか比べてみる。
  • 同じ処理を async / await 版と then / catch 版で両方書いてみて、「中で何が起きているか」を自分の言葉で説明してみる。

そうやって「自分の頭で理解した fetch & GET の型」を一度作ってしまうと、その後の API 通信全般が一段クリアに見えてきます。

スポンサーリンク
タイトルとURLをコピーしました