コンテンツにスキップ
新人エンジニア研修 v1.4

10-4. 演習問題

問題1：選択問題

Section titled “問題1：選択問題”

1-1. 新しい書籍を作成する API に最も適切な HTTP メソッドはどれか。

  • A. POST
  • B. GET
  • C. DELETE
解答と解説

正解：A. POST

  • A が正しい。新しいリソースを作る操作に対応する。
  • B は誤り。GET は取得用である。
  • C は誤り。DELETE は削除用である。

1-2. /api/books/{id} の {id} を受け取る注釈として最も適切なのはどれか。

  • A. @PathVariable
  • B. @RequestParam
  • C. @Autowired
解答と解説

正解：A. @PathVariable

  • A が正しい。URL パス中の値を受け取る。
  • B は誤り。@RequestParam はクエリパラメータ向けである。
  • C は誤り。依存性注入に関わるものであり、パス受け取りではない。

1-3. リクエスト本文の JSON を Java オブジェクトとして受け取る注釈として最も適切なのはどれか。

  • A. @RequestBody
  • B. @Component
  • C. @Bean
解答と解説

正解：A. @RequestBody

  • A が正しい。JSON 本文を Java オブジェクトへ変換する。
  • B と C は誤り。Spring の部品定義に関する注釈である。

1-4. 新規作成成功を表す HTTP ステータスとして最も適切なのはどれか。

  • A. 201 Created
  • B. 404 Not Found
  • C. 500 Internal Server Error
解答と解説

正解：A. 201 Created

  • A が正しい。新規作成の成功を表す。
  • B と C は失敗系であり不適切である。

1-5. タイトル空欄など入力値が不正だったときに最も自然なステータスはどれか。

  • A. 400 Bad Request
  • B. 204 No Content
  • C. 301 Moved Permanently
解答と解説

正解：A. 400 Bad Request

  • A が正しい。入力値が API の期待する形式や制約に合っていない。
  • B は成功系であり不適切である。
  • C はリダイレクトであり無関係である。

問題2：穴埋め問題

Section titled “問題2：穴埋め問題”

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

  1. API の入力や出力の形を表すオブジェクトを （　　　） という。
  2. JSON 本文を Java オブジェクトとして受け取る注釈は @**（　　　）** である。
  3. URL の一部として渡された ID を受け取る注釈は @**（　　　）** である。
  4. 入力制約を有効にするために Controller 引数へ付ける注釈は @**（　　　）** である。
  5. 削除成功で本文を返さないときによく使うステータスは **（　　　）** No Content である。
解答欄
解答と解説

  1. DTO

    API の外向けの形を表すオブジェクトである。

  2. RequestBody

    JSON 本文を Java へ変換して受け取る注釈である。

  3. PathVariable

    URL の一部をメソッド引数へ渡す。

  4. Valid

    DTO に付けた制約を有効にするために使う。

  5. 204

    本文なしの成功を表す代表的なステータスである。

問題3：記述問題

Section titled “問題3：記述問題”

3-1. DTO を使って入出力を分ける利点を説明してください。

解答欄
解答と解説

3-1. DTO の利点

DTO を使うと、内部モデルと API の入出力を分けられる。これにより、内部構造を変更しても API 契約を保ちやすくなり、後で Entity やサービス構造が変わっても影響を閉じ込めやすい。

3-2. 400 と 404 を返し分ける理由を説明してください。

解答欄
解答と解説

3-2. 400 と 404 を返し分ける理由

400 は入力そのものが不正なとき、404 は指定した対象が見つからないときに使う。原因が違うため、呼び出し側が何を直せばよいかも変わる。ステータスを使い分けることで、利用者にも開発者にも意図が伝わりやすくなる。

3-3. なぜブラウザ側でバリデーションしていても、サーバー側で再度チェックする必要があるのか説明してください。

解答欄
解答と解説

3-3. サーバー側でもチェックする理由

ブラウザ以外のクライアントから API が呼ばれる可能性があるからである。フロントエンドのチェックをすり抜けても、サーバー側で防げるようにしておく必要がある。

問題4：ハンズオン

Section titled “問題4：ハンズオン”

4-1. curl で CRUD を試す

Section titled “4-1. curl で CRUD を試す”

自分の API に対して、curl を 1 本ずつ実行し、そのたびにステータスコードと本文を確認してください。

VS Code で進める手順

Section titled “VS Code で進める手順”
  1. book-app/bookmanager/ を VS Code で開く
  2. 1本目のターミナルで ./gradlew bootRun を実行し、サーバーを起動したままにする
  3. 2本目のターミナルを開き、以下の curl を 1つずつ試す
  4. curl -i で表示されるステータス行と、サーバーログの内容を見比べる
  5. 1 本終わるたびに、「何が増えたか / 変わったか / 消えたか」を確認してから次へ進む

-i はレスポンスヘッダも表示するため、200 / 201 / 204 を目で確認しやすい。
-H は HTTP ヘッダ、-d は送信する JSON 本文を表している。

  1. まず一覧取得を試す
Terminal window
curl -i http://localhost:8080/api/books

確認すること:

  • HTTP/1.1 200 が返るか
  • JSON 配列で初期データが返るか
  1. 次に新規作成を試す
Terminal window
curl -i -X POST http://localhost:8080/api/books \
  -H 'Content-Type: application/json' \
  -d '{"title":"DDD入門","author":"成瀬允宣","category":"バックエンド","price":3800,"status":"未読","memo":"あとで読む"}'

確認すること:

  • HTTP/1.1 201 が返るか
  • レスポンス本文に id と title が入っているか
  1. 状態更新を試す
Terminal window
curl -i -X PATCH http://localhost:8080/api/books/1 \
  -H 'Content-Type: application/json' \
  -d '{"status":"読了"}'

確認すること:

  • HTTP/1.1 200 が返るか
  • status が 読了 へ変わっているか
  1. 削除を試す
Terminal window
curl -i -X DELETE http://localhost:8080/api/books/1

確認すること:

  • HTTP/1.1 204 が返るか
  • 本文がなくても成功として扱われているか
  1. 最後にもう一度一覧取得を試す
Terminal window
curl -i http://localhost:8080/api/books

確認すること:

  • 先ほど削除した本が含まれていないか
  1. 不正値送信も試す
Terminal window
curl -i -X POST http://localhost:8080/api/books \
  -H 'Content-Type: application/json' \
  -d '{"title":"","author":"","category":"","price":-1,"status":""}'

確認すること:

  • HTTP/1.1 400 が返るか
  • errors に項目ごとの理由が入っているか

4-2. 故障シナリオを切り分ける

Section titled “4-2. 故障シナリオを切り分ける”

次の症状が出たとき、まず何を確認するか書いてください。

  1. POST /api/books で 400 になる
  2. GET /api/books/999 で 500 になってしまう
  3. DELETE /api/books/1 のあとに本文が返ってくる
解答欄
解答と解説

4-1. curl で確認する意義

一覧取得・登録・更新・削除を HTTP レベルで直接確認できるため、ブラウザ UI を介さず API の外形が正しいかを見極めやすい。特にステータスコードと JSON 本文を確認することが重要である。

4-2. 故障シナリオの切り分け

  1. POST /api/books で 400

    • JSON のキー名と DTO フィールド名が一致しているか
    • 必須項目や @Min 条件に違反していないか

  2. GET /api/books/999 で 500

    • 見つからないケースを例外処理して 404 に変換しているか
    • サーバーログでどの例外が起きているか確認する

  3. DELETE /api/books/1 のあとに本文が返ってくる

    • 設計として 204 No Content にしたいなら、Controller の戻り値や @ResponseStatus を見直す