web.phpとapi.phpの違い

1. 位置づけと登録タイミング

---

2. 付与される既定ミドルウェアの違い

要点

• web ルートは「状態あり」。ブラウザ Cookie を用いたログインセッションや CSRF トークンを前提にする。

• api ルートは「状態なし」。基本は Cookie を送らず、CSRF チェックも無効。トークンやヘッダーに認証情報を載せる。

---

3. URL／名前付きルートのプレフィックス

• api.php は自動的に /api で始まる。
  例: Route::get('/users', ...) → 実際のエンドポイント /api/users

• web.php にはプレフィックスが付かない（必要なら開発者が Route::prefix() で任意に付与）。

---

4. レート制限とセキュリティ

• api ルートには Throttle:api がデフォルトで適用され、.env の API_RATE_LIMIT（Laravel 11）や RateLimiter クラスで制御可能。

• web ルートはレート制限が無効（必要なら個別に throttle ミドルウェアを割り当てる）。

• どちらのファイルでも追加のミドルウェアをチェーンできるが、意図せず CSRF やセッションを有効／無効にしないよう注意。

---

5. 認証ガードとの組み合わせ

---

6. テスト戦略の差異

• Feature テスト

  • web.php: actingAs($user)->get('/') などセッションを張ったブラウザインタラクションを模倣。

  • api.php: withHeaders(['Authorization'=>'Bearer …'])->json('GET', '/api/users') のようにステートレス呼び出し。

• API リソースクラスは api.php ルートで使うとシリアライズ済みの JSON が自動生成され、web.php 側の Blade とは責務が分離される。

---

7. 実運用におけるベストプラクティス

1. 用途ごとに責務を分離

   • 画面表示やフォーム送信は web.php。

   • データ提供（JSON/XML 等）は api.php。

2. CSRF を二重にかけない

   • api.php に CSRF ミドルウェアを追加するとモバイルアプリからの呼び出しが失敗しやすい。

3. バージョニング戦略

   • API は長寿命を想定し Route::prefix('v1')->group(function () { … }); のように api.php 側でバージョンを切る。

   • web.php 側は UI の変更に合わせて都度ルートが変わってもよい。

4. ドメイン境界の明確化

   • 多言語サイトやサブドメイン切替えは web.php に Route::domain()。

   • API 用に api.example.com を用意する場合は RouteServiceProvider で mapApiRoutes() を拡張し、api.php を該当ドメインにバインド。

---

8. まとめ

• web.php はセッション／CSRF を前提とした「人間のブラウザ」向けルート。

• api.php はステートレスでレート制限付き「機械（アプリ／他サービス）」向けルート。

• ミドルウェア、URL プレフィックス、認証方式が初期設定で分かれており、責務とセキュリティモデルの混線を防ぐことが最大の目的。

この切り分けを踏まえ、開発初期に「どのルートファイルに何を置くか」を合意しておくと、後々の保守性とセキュリティが大幅に向上します。