LLaravel Bootcamp

Day 3・ルーティングとコントローラー、ルートモデルバインディング

リクエストとレスポンス

入力を受け取るRequest、返し方(リダイレクト・JSON)とステータスコードの基本を理解する。

Requestオブジェクト

ユーザーが送ってきた入力(フォームの値、クエリ文字列、ヘッダーなど)は、Requestオブジェクトにまとめられてコントローラに渡ってきます。コントローラのメソッドの引数に型を書いておけば、Laravelが自動でこのオブジェクトを用意してくれます。

PHP
use Illuminate\Http\Request;

public function store(Request $request)
{
    $title = $request->input('title');      // 特定の項目を取り出す
    $all   = $request->only(['title', 'body']); // 必要な項目だけ
    $page  = $request->query('page', 1);    // クエリ文字列(既定値つき)

    // 生の $request->all() をそのまま保存するのは避ける([[mass-assignment]] 対策)
}
Requestから入力を取り出す

落とし穴: 生の入力をそのまま保存しない

「$request->all()」で受け取った内容をそのままモデルに保存すると、意図しない項目まで書き込まれる のリスクがあります。必要な項目だけをonlyで絞るか、バリデーション済みの値(validated())を使うのが安全です。入力は信用しない、が原則です。

レスポンスの返し方

処理の結果は「レスポンス」として返します。Webの画面ならビュー(HTML)やリダイレクト、APIならJSONを返すのが基本です。用途によって返し方を選びます。

PHP
// HTMLを返す
return view('posts.index', ['posts' => $posts]);

// 保存後は一覧へリダイレクト。処理の重複送信も防げる
return redirect()->route('posts.index')
    ->with('status', '投稿を保存しました'); // 一度だけ表示されるメッセージ
画面向け: ビューとリダイレクト

なぜ保存後にリダイレクトするのか(PRGパターン)

フォーム送信(POST)の直後に画面をそのまま表示すると、ユーザーがブラウザを再読み込みしたときに同じ送信が繰り返され、二重登録が起きます。保存後に別URLへリダイレクト(GET)させる「PRG(Post/Redirect/Get)」にすると、再読み込みしても登録処理が走らず安全です。これは定番の設計パターンです。

PHP
// 取得成功。既定で 200 OK
return response()->json($post);

// 新規作成の成功は 201 Created を返すのが作法
return response()->json($post, 201);

// 見つからないときは 404 Not Found
return response()->json(['message' => 'not found'], 404);
API向け: JSONレスポンスとステータスコード

ステータスコードの基本

HTTPステータスコードは「処理の結果を数字で伝える共通言語」です。特にAPIでは、呼び出し側がこの数字を見て成功・失敗を判断するので、正しく返すことが大切です。

  • 200 OK: 取得・更新などが成功した。
  • 201 Created: 新規作成に成功した(POSTで作った直後)。
  • 204 No Content: 成功したが返す本文がない(削除など)。
  • 302 / リダイレクト: 別のURLへ誘導する(Web画面でよく使う)。
  • 404 Not Found: 対象が見つからない。
  • 422 Unprocessable: 入力の検証に失敗した(バリデーションエラー)。
  • 500 Internal Server Error: サーバ側で予期しない例外が起きた。

補足

「成功なら何でも200を返す」のではなく、作成なら201、削除なら204、というように意味の合ったコードを返すと、APIを使う側の実装が素直になります。

面接ではこう言う

「入力はRequestオブジェクトから受け取りますが、生のall()をそのまま保存せず、バリデーション済みの値を使ってマスアサインメントを避けます。Web画面ではPRGパターンで保存後にリダイレクトし、二重送信を防ぎます。APIでは結果に応じて201・404・422など意味の合ったステータスコードを返す、という基本を守っています」と言えます。

読んでも腑に落ちない所は、AIに噛み砕いてもらいましょう。

理解度チェック

答えられれば、面接で説明できる状態に一歩近づきます。

Q1

フォーム送信(POST)後に、あえて別URLへリダイレクトする(PRGパターン)主な理由はどれか。

Q2

APIで新しいリソースの作成に成功したとき、返すべきステータスコードとして最も適切なものはどれか。

Q3

「$request->all() をそのまま保存してはいけない」と言われる理由を説明せよ。

記述式です。まず自分の言葉で答えを考えてから、模範解答を開いて自己採点してください。