リクエストが届くまでの全体像（まとめ）

導入

ここまで、Controller・URLマッピング・JSON変換・DTOと部品を1つずつ見てきました。最後に、これらをつなげて「クライアントのリクエストが、実際にどんな経路を通ってレスポンスになるのか」を1枚の図にまとめます。

説明

典型的なREST APIリクエストの流れは、次のようになります。

sequenceDiagram
    participant C as クライアント（ブラウザ/アプリ）
    participant DS as DispatcherServlet<br/>（SpringのWeb入口）
    participant Ctrl as Controller
    participant Svc as Service
    participant Repo as Repository
    participant DB as データベース

    C->>DS: HTTPリクエスト（例: GET /api/users/5）
    DS->>Ctrl: URLに一致するメソッドを呼び出す
    Ctrl->>Svc: 業務ロジックを依頼する
    Svc->>Repo: データの取得を依頼する
    Repo->>DB: SQLを発行する
    DB-->>Repo: 結果の行を返す
    Repo-->>Svc: Entityに変換して返す
    Svc-->>Ctrl: DTOに変換して返す
    Ctrl-->>DS: DTOオブジェクトを返す
    DS-->>C: JSONに変換してレスポンスとして返す

DispatcherServlet は、すべてのHTTPリクエストの最初の受け口です。「どのURLがどのControllerのどのメソッドに対応するか」の表を持っていて、リクエストを適切なメソッドへ振り分けます（これも自動構成によって、開発者が意識せず使えるようになっています）。

各層の役割を、あらためて一言でまとめておきます。

この「Controller → Service → Repository」という積み重ねは、次章「データアクセス」と、第6章「実践」でさらに詳しく扱います。ここでは、1つのリクエストが複数の層を順番に通り抜けて、レスポンスとして戻ってくるという全体の流れを、絵として頭に入れておいてください。

やってみよう

上のシーケンス図を見ずに、自分で「クライアントがGETリクエストを送ってから、JSONが返るまで」の流れを言葉で説明してみましょう。どの層で何をしているか、詰まる部分があれば、その層をもう一度読み返してみてください。