2-2. 演習問題

問題1：選択問題

1-1. GET /books/42 の主な目的として最も適切なのはどれか。

A. 本を1冊取得する
B. 本を新規作成する
C. 本を削除する

1-2. 404 ステータスコードの意味として最も適切なのはどれか。

A. 認証は通ったが権限がない
B. リクエストした URL に対応する資源が見つからない
C. サーバーが正常に処理を完了した

1-3. Cookie の役割として最も適切なのはどれか。

A. サーバーの IP アドレスを変更する
B. リクエスト間で状態を引き継ぐための情報を持つ
C. DNS の問い合わせ先を記録する

1-4. REST 的な設計として最も自然なのはどれか。

A. GET /deleteBook?id=42
B. PATCH /books/42
C. POST /showBook/42

1-5. 認証の説明として最も適切なのはどれか。

A. 本人が誰かを確認すること
B. データを暗号化すること
C. URL を人に読みやすくすること

1-6. 未ログインのため認証情報が必要なとき、もっとも典型的なのはどのステータスコードか。

A. 200
B. 401
C. 403

問題2：穴埋め問題

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

ブラウザとサーバーが Web 上で会話するためのルールを （　　　） という。
サーバーが返す 200 や 404 のような番号を （　　　） という。
HTTP が基本的に前回の会話を自動では覚えない性質を （　　　） という。
ブラウザが保存し、次回以降のリクエストで送る小さなデータを （　　　） という。
「あなたは誰か」を確認することを （　　　） という。
本一覧を表す REST 的な URL の例は （　　　） である。

解答欄

問題3：記述問題

3-1. HTTP がステートレスであるとはどういう意味か、そしてなぜ Cookie が必要になるのか説明してください。

解答欄

3-2. 401 と 403 の違いを説明してください。

解答欄

3-3. REST では、なぜ URL に資源、メソッドに操作を持たせるのか説明してください。

解答欄

3-4. 認証と認可の違いを説明してください。

解答欄

問題4：ハンズオン

Git Bash を使って、HTTP の様子を観察してみましょう。

① ヘッダーを確認する

curl -I https://example.com

ステータス行（例：HTTP/2 200 や HTTP/1.1 200 OK）を確認する
content-type などのヘッダーが返ることを確認する

② JSON を確認する

curl https://api.github.com/repos/octocat/Hello-World | head -n 20

JSON の形でデータが返ることを確認する
full_name や html_url のような項目が見えることを確認する

③ メソッドと資源を言葉で説明する

次のリクエストを見て、「何をしたいリクエストか」を説明する。

GET /books/42 HTTP/1.1
Host: api.example.com

④ エラーメッセージを記録する

もし curl が失敗したら、どの URL で、どのエラーメッセージが出たかを控える。

解答

問題1の解答（クリックで開く）

1-1. 正解：A. 本を1冊取得する

解説

A が正しい。GET は取得を表し、/books/42 は 42 番の本という資源を指している。

B は誤り。新規作成なら通常 POST /books を使う。

C は誤り。削除なら通常 DELETE /books/42 を使う。

1-2. 正解：B. リクエストした URL に対応する資源が見つからない

解説

A は 403 に近い意味である。

B が正しい。404 は「その URL に対応する資源が見つからない」を表す。

C は 200 の意味である。

ステータスコードは、HTTP 通信の結果を一目で把握するための重要な手掛かりである。

1-3. 正解：B. リクエスト間で状態を引き継ぐための情報を持つ

解説

A は誤り。IP アドレスの変更は Cookie の役割ではない。

B が正しい。Cookie はブラウザが保存し、次のリクエストでも送ることで状態継続に使われる。

C は誤り。DNS の問い合わせ先を記録する仕組みではない。

1-4. 正解：B. PATCH /books/42

解説

A は URL の中に操作名 deleteBook を埋め込んでおり、REST 的には不自然である。

B が正しい。/books/42 という資源に対し、PATCH という操作を分離して表現している。

C も URL に操作名 showBook が入っており、資源より操作が前面に出ている。

1-5. 正解：A. 本人が誰かを確認すること

解説

A が正しい。認証は「あなたは誰か」を確認すること。

B の暗号化は TLS など別の仕組み。

C の URL を読みやすくする役割は DNS や REST の設計に関係する話で、認証ではない。

1-6. 正解：B. 401

解説

B が正しい。未ログインなどで認証情報が必要な場合の典型例が 401 である。

C の 403 は、認証済みでも権限が足りない場合に使われる。

A の 200 は成功であり、認証不足とは逆である。

問題2の解答（クリックで開く）

HTTP

ブラウザとサーバーが Web 上でやり取りするための通信ルールである。

ステータスコード

リクエストの結果を表す番号。成功か、認証不足か、見つからないか、サーバーエラーかを把握できる。

ステートレス

HTTP が基本的に各リクエストを独立したものとして扱う性質である。

Cookie

ブラウザが保存し、次回以降のリクエストで送る小さなデータ。状態継続に使う。

認証

「あなたは誰か」を確認すること。ログインは代表例である。

/books

本の集合を表す REST 的な URL の例である。個別の本なら /books/42 のように書く。

問題3の解答例（クリックで開く）

3-1. ステートレスと Cookie の関係

HTTP がステートレスであるとは、サーバーが前回のリクエスト内容を自動では覚えないことを意味する。そのままではログイン状態を継続できないため、ブラウザが Cookie を保存し、次のリクエストでも送ることで「この人は前回ログインした人だ」と判断できるようにする。つまり Cookie は、ステートレスな HTTP の上で状態継続を実現するための手段である。

3-2. 401 と 403 の違い

401 は、まず認証情報が必要であることを示す。一方 403 は、誰かは分かっているが、その操作を許可できないことを示す。つまり 401 は認証不足、403 は権限不足と整理できる。

3-3. REST で URL とメソッドを分ける理由

URL に資源を、メソッドに操作を持たせると、API の意味が読みやすくなる。たとえば /books/42 は常に「42番の本」という対象を指し、GET なら取得、PATCH なら更新、DELETE なら削除と分かれる。この分離により、設計ルールをそろえやすく、保守もしやすくなる。

3-4. 認証と認可の違い

認証は「あなたは誰か」を確認すること、認可は「その人にその操作を許すか」を決めることである。たとえばログイン成功は認証、管理者画面へ入れるかどうかは認可の問題である。実務ではこの2つを混同すると、401 と 403 の使い分けや設計判断を誤りやすい。

問題4の解答例（クリックで開く）

① ヘッダーを確認する

Terminal window
$ curl -I https://example.com
HTTP/2 200
content-type: text/html
...
実際の表示は環境によって少し異なるが、ステータス行とヘッダーが返ることが重要である。 -I を付けると本文ではなくヘッダー中心に確認できるため、通信の全体像をつかみやすい。

② JSON を確認する

Terminal window
$ curl https://api.github.com/repos/octocat/Hello-World | head -n 20
{
  "id": ...,
  "full_name": "octocat/Hello-World",
  "private": false,
  "html_url": "https://github.com/octocat/Hello-World",
  ...
これにより、Web API は HTML だけでなく JSON も返せることが分かる。 REST API では、URL に対応する資源の表現として JSON が返る場面が多い。

③ メソッドと資源を言葉で説明する

GET /books/42 HTTP/1.1
Host: api.example.com
このリクエストは、「api.example.com というサーバーに対して、42番の本の情報を取得したい」という意味である。 GET が操作、/books/42 が資源を表している。

④ エラーメッセージを記録する

たとえば curl: (6) Could not resolve host なら DNS 周り、curl: (7) Failed to connect なら接続先やポート周り、401 や 403 なら HTTP レベルの問題と考えられる。どの URL で何が出たかを残すことで、レイヤーごとの切り分けができるようになる。