10-5. 演習問題

実アプリ側でも確認するときは、book-app/book-frontend/ で npx --yes serve . --listen 4173 を実行して起動し、http://localhost:4173/ を開く。終わったら Ctrl + C で停止する。

問題1：選択問題

1-1. fetch() が返す値として最も適切なのはどれか。

A. Promise
B. CSS クラス
C. HTML テーブル

解答と解説

正解：A. Promise

A が正しい。fetch() は非同期処理なので Promise を返す。
B は誤り。CSS クラスは返さない。
C は誤り。HTML テーブルも返さない。

そのため await や .then() で結果を待つ必要がある。

1-2. 新しい本をサーバーへ追加するときに最も適切な HTTP メソッドはどれか。

A. POST
B. GET
C. DELETE

解答と解説

正解：A. POST

A が正しい。新規作成は POST が代表的である。
B は誤り。GET は取得用であり、データ変更を目的としない。
C は誤り。DELETE は削除用である。

HTTP メソッドは「何をしたいか」を表す言葉でもある。

1-3. response.ok を確認する主な理由として最も適切なのはどれか。

A. HTTP 的に成功かどうかを判断するため
B. CSS が読み込まれたかを確認するため
C. 表示中のフォントを確認するため

解答と解説

正解：A. HTTP 的に成功かどうかを判断するため

A が正しい。400 や 500 は通信自体は返ってきても業務的には失敗である。
B は誤り。CSS 読み込み確認には使わない。
C は誤り。フォント確認とも無関係である。

fetch() はエラー時も必ず catch に入るわけではないため、ok を見る必要がある。

1-4. 削除 API が 204 No Content を返したときの扱いとして最も適切なのはどれか。

A. 本文が空でも成功として扱い、無理に JSON を読まない
B. 必ず response.json() を呼ばないと失敗になる
C. PATCH と同じ扱いにする

解答と解説

正解：A. 本文が空でも成功として扱い、無理に JSON を読まない

A が正しい。204 は「成功だが本文なし」を意味することが多い。
B は誤り。本文がないのに json() を呼ぶと逆にエラー要因になる。
C は誤り。PATCH と DELETE は役割もレスポンスも違うことがある。

API ごとの仕様を見ることは大切だが、204 では本文なしの可能性を常に意識したい。

1-5. 通信成功・失敗に関係なく最後にローディングを解除したいとき、最も向いているのはどれか。

A. finally
B. break
C. continue

解答と解説

正解：A. finally

A が正しい。成功でも失敗でも最後に必ず通る。
B と C はループ制御であり、非同期通信の後始末には向かない。

ローディング解除の書き忘れを防ぐためにも finally は重要である。

1-6. Network タブで「送った JSON 本文」を確認したいとき、主に見る場所として最も適切なのはどれか。

A. Payload
B. Elements
C. Rendering

解答と解説

正解：A. Payload

A が正しい。送信本文は Payload で確認できる。
B は誤り。Elements は DOM 構造を見る場所である。
C は誤り。Rendering は描画系の確認に使う。

「送ったつもり」の内容と「実際に送られた JSON」は違うことがあるため、Payload を見る習慣が大切である。

問題2：穴埋め問題

次の文章の空欄を埋めてください。

fetch() の待ち時間を上から順に読みやすく書くためによく使う構文は async / （　　　） である。
一覧取得に使う代表的な HTTP メソッドは （　　　） である。
新規作成に使う代表的な HTTP メソッドは （　　　） である。
一部更新に使う代表的な HTTP メソッドは （　　　） である。
削除に使う代表的な HTTP メソッドは （　　　） である。
実際に飛んだ通信の URL・Method・Status を確認する主要な場所は DevTools の （　　　） タブである。

解答欄

解答と解説

await
GET
POST
PATCH
DELETE
Network

await を使うと Promise の完了を待ちながら順番に読める。
GET / POST / PATCH / DELETE は REST API の基本的な操作を表す。
Network タブは実際に飛んだ通信を確認する最重要ポイントである。

これらの単語は暗記ではなく、「どの操作に対応しているか」を結び付けて覚えることが重要である。

問題3：記述問題

3-1. 10-3 のブラウザ内 state 版と比べて、10-5 で API 連携が必要になる理由を説明してください。

解答欄

解答と解説

3-1. 例

ブラウザ内 state 版はその場の画面更新には向いているが、別端末や別利用者と共有することはできない。API 連携があると、サーバー側でデータを一元管理でき、複数環境から同じデータを見たり、検索・認可・監査のような処理も追加しやすくなる。つまり API は「保存場所をブラウザの外へ広げる」ために必要である。

3-2. ローディング表示とエラー表示を用意しておくことが、なぜ利用者と開発者の両方にとって重要なのか説明してください。

解答欄

解答と解説

3-2. 例

ローディング表示があると利用者は「いま処理中だ」と分かり、同じボタンの連打を減らしやすい。エラー表示があると、失敗したことと次に見るべき内容が分かる。開発者にとっても、どの操作でどんな失敗が起きたかを画面上で再現しやすく、Console や Network と合わせて原因を調べやすくなる。

3-3. response.ok を確認しないと、どのような勘違いが起きやすいか説明してください。

解答欄

解答と解説

3-3. 例

response.ok を確認しないと、HTTP 400 や 500 でも「値は返ってきた」と誤解して成功扱いしやすい。その結果、本来は失敗なのに state を更新したり、エラーメッセージを出さずに処理を進めてしまったりする。API 連携では「通信できた」ことと「業務的に成功した」ことを分けて考える必要がある。

3-4. API 呼び出しで 400 エラーが返ったとき、Network タブを使って何を確認するか説明してください。

解答欄

解答と解説

3-4. 例

まず該当リクエストを Network タブで開き、Method と Status が想定通りか確認する。次に Headers で URL が正しいか、Payload で送った JSON に title や price が入っているかを見る。そのうえで Response や Preview に表示されるエラーメッセージを読み、送信値の不足なのか、型の間違いなのか、API パスの誤りなのかを切り分ける。

問題4：ハンズオン

プレイグラウンドで、fetch に似た動きをする fakeFetch を使って通信の流れを確認してみましょう。このプレイグラウンドでは本物のネットワーク通信は行わないため、Network タブには出ません。その代わり、Console に Method / URL / loading / 結果 を順番に表示します。

ここでは、TODO を 1 つ埋めるたびに実行し、どの HTTP 操作が増えたかを順番に観察します。
実アプリで確認するときは、同じ順番で script.js を保存 → ブラウザ更新 → Network 確認を行ってください。

実行プレイグラウンド

編集内容は自動保存されます / Ctrl+Enter でも実行できます

const fakeDb = [
{ id: "b1", title: "JavaScript入門", author: "山田太郎", category: "フロントエンド", price: 2800, status: "未読", memo: "DOM 章まで読む" },
{ id: "b2", title: "Git実践入門", author: "佐藤花子", category: "開発ツール", price: 2400, status: "読書中", memo: "レビュー運用を復習" },
];

function wait(ms) {
return new Promise((resolve) => setTimeout(resolve, ms));
}

function makeResponse(status, data) {
return {
  ok: status >= 200 && status < 300,
  status,
  async json() { return data; },
};
}

async function fakeFetch(url, options = {}) {
const method = (options.method || "GET").toUpperCase();
console.log("HTTP", method, url);
await wait(50);
if (url === "/api/books" && method === "GET") {
  return makeResponse(200, fakeDb.slice());
}
if (url === "/api/books" && method === "POST") {
  const payload = JSON.parse(options.body || "{}");
  if (!payload.title) return makeResponse(400, { message: "title is required" });
  const created = { id: "b3", ...payload };
  fakeDb.unshift(created);
  return makeResponse(201, created);
}
const match = url.match(/^/api/books/(.+)$/);
if (!match) return makeResponse(404, { message: "not found" });
const bookId = match[1];
const index = fakeDb.findIndex((book) => book.id === bookId);
if (index === -1) return makeResponse(404, { message: "book not found" });
if (method === "PATCH") {
  const patch = JSON.parse(options.body || "{}");
  fakeDb[index] = { ...fakeDb[index], ...patch };
  return makeResponse(200, fakeDb[index]);
}
if (method === "DELETE") {
  fakeDb.splice(index, 1);
  return { ok: true, status: 204, async json() { throw new Error("No content"); } };
}
return makeResponse(405, { message: "method not allowed" });
}

async function requestJSON(url, options = {}) {
const response = await fakeFetch(url, options);
if (response.status === 204) return null;
const data = await response.json();
if (!response.ok) throw new Error(data.message || "HTTP error");
return data;
}

function setLoading(value) { console.log("loading:", value); }

(async () => {
// TODO 1: GET /api/books で一覧を取得し、「初期冊数:」と冊数を console.log する
try {
  setLoading(true);

} finally {
  setLoading(false);
}

// TODO 2: POST /api/books で1冊追加し、「追加タイトル:」と created.title を console.log する
// body: { title: "CSS設計の基本", author: "高橋健", category: "フロントエンド", price: 2600, status: "未読", memo: "命名を見直す" }
try {
  setLoading(true);

} finally {
  setLoading(false);
}

// TODO 3: PATCH /api/books/b3 で { status: "読了" } に更新し、「更新後ステータス:」と updated.status を console.log する
try {
  setLoading(true);

} finally {
  setLoading(false);
}

// TODO 4: DELETE /api/books/b3 で削除し、「削除後冊数:」と fakeDb.length を console.log する
try {
  setLoading(true);

} finally {
  setLoading(false);
}

// TODO 5: title が空の POST /api/books を試み、catch で「最後のエラー:」と error.message を console.log する
// body: { title: "", author: "誰か", category: "フロントエンド", price: 1000, status: "未読", memo: "" }
try {
  setLoading(true);

} catch (error) {

} finally {
  setLoading(false);
}
})();

出力

「実行」を押すと、ここに結果が表示されます。

取り組む内容

TODO 1 を埋めて実行し、GET /api/books と初期冊数だけが出ることを確認する
ここで止まり、実アプリでもページ更新直後の GET /api/books を Network で確認する
TODO 2 を埋めて実行し、POST /api/books と追加タイトルが出ることを確認する
ここで止まり、実アプリでもフォーム送信による POST /api/books と一覧追加を確認する
TODO 3 を埋めて実行し、PATCH /api/books/b3 と更新後ステータスが出ることを確認する
ここで止まり、実アプリでも状態変更による PATCH /api/books/{id} を確認する
TODO 4 を埋めて実行し、DELETE /api/books/b3 と削除後冊数が出ることを確認する
ここで止まり、実アプリでも削除による DELETE /api/books/{id} を確認する
TODO 5 を埋めて実行し、最後にエラー文言が出ることを確認する
最後に実アプリでも不正入力のエラー表示と失敗レスポンスを確認する
method: "PATCH" を "PUT" に変えて再実行し、想定外メソッドの扱いを観察する

確認したいポイント

setLoading(true/false) が try/finally で必ず対になっていることを確認する
TODO 5 の try は catch も持つ — エラー時は catch を通ってから finally が動くことを確認する
requestJSON 内で response.ok を確認しないと 400 エラーが成功扱いになる理由を理解する

実アプリで同じ順番に確認するなら

まず GET /api/books が自動で飛ぶことを Network で見る
次にフォーム送信で POST /api/books が 201 になることを確認する
その次に状態変更で PATCH /api/books/{id} が 200 になることを確認する
続いて削除で DELETE /api/books/{id} が 204 になることを確認する
最後に不正入力でエラー表示と失敗レスポンスを確認する

期待する出力例

loading: true
HTTP GET /api/books
初期冊数: 2
loading: false
loading: true
HTTP POST /api/books
追加タイトル: CSS設計の基本
loading: false
loading: true
HTTP PATCH /api/books/b3
更新後ステータス: 読了
loading: false
loading: true
HTTP DELETE /api/books/b3
削除後冊数: 2
loading: false
loading: true
HTTP POST /api/books
最後のエラー: title is required
loading: false

解答と解説

このハンズオンで確認したいこと

GET で一覧を読む
POST で 1 冊追加する
PATCH で状態を更新する
DELETE で削除する
エラー時にも finally で loading を戻す

出力の読み方

HTTP GET /api/books の直後に 初期冊数: 2 が出る → 一覧取得成功
HTTP POST /api/books の直後に 追加タイトル: CSS設計の基本 が出る → 新規作成成功
HTTP PATCH /api/books/b3 の直後に 更新後ステータス: 読了 が出る → 一部更新成功
HTTP DELETE /api/books/b3 の直後に 削除後冊数: 2 が出る → 削除後の状態が反映された
最後の HTTP POST /api/books で 最後のエラー: title is required が出る → response.ok 判定とエラー処理が効いている

response.ok 判定を消すと何が起きるか 400 エラーのレスポンスでも成功データのように扱ってしまい、失敗を正しく表現できなくなる。API 連携では非常に危険な状態である。

実アプリでの確認ポイント プレイグラウンドは fakeFetch なので Network タブには出ないが、実アプリでは同じ順番で GET / POST / PATCH / DELETE が並ぶはずである。Network タブでその順番と Payload / Response を見比べると、フロントエンドの処理と実通信の対応が理解しやすくなる。