サーバー内部のリクエストライフサイクル

クライアントがサーバーに HTTP リクエストを送ると、システムはすぐにビジネスロジックを実行するわけではありません。代わりに、リクエストは定義された一連のステップを通過します。このパイプラインによって、ルーティング、認証、データ処理などの各関心事が正しい順序で処理されます。

一般的なライフサイクルは次のようになります:

HTTPリクエスト
↓
ルーター
↓
ミドルウェア
↓
認証
↓
ビジネスロジック
↓
データベース
↓
HTTPレスポンス

この構造は任意ではなく、現代のバックエンドフレームワークがこのように設計されているということです。Express、Django、Spring Boot、FastAPI のいずれを使う場合でも、すべてのシステムはこのパイプラインの何らかの変種を実装しています。

利点は、制御しやすく予測可能であることです。責務を混在させるのではなく、各ステップに明確な目的があります。エンジニアは、特定のポイントにロジックを挿入できます（たとえば、ビジネスロジックの前に認証を追加するなど）。その際、システムの他の部分に影響を与えません。

このパイプラインがなければ、バックエンドシステムはすぐに混乱し、バリデーション、セキュリティ、ビジネスロジックが絡み合ってしまいます。構造化されたフローによって、リクエストは一貫して、安全に、効率よく処理されます。

リクエストがサーバーに届いたとき、最初の大きな判断は「どのコードがこれを処理するのか？」です。これがルーターの役割です。

ルーターは、リクエストの 2 つの重要な要素、URL パスと HTTP メソッドを確認します。これらを組み合わせることで、クライアントが何をしようとしているのかを一意に識別できます。

例:

GET /users
→ usersController.getUsers

POST /orders
→ ordersController.createOrder

同じ URL を使う 2 つのリクエストでも、HTTP メソッドが異なれば、まったく別のロジックにルーティングできます。これにより、API はデータの取得（GET）とデータの作成（POST）のような操作を明確に分離できます。

内部では、フレームワークがリクエストパターンをハンドラー関数にマッピングするルーティングテーブルを管理しています。リクエストがルートに一致すると、対応するハンドラーが実行されます。

この抽象化によって、システムは整理された状態に保たれます。すべてのリクエストを手動で調べる条件分岐を書く代わりに、開発者はルートを宣言的に定義します。フレームワークが効率的に照合を行い、毎回正しいコードが実行されるようにします。

Middleware は、受信したリクエストと、それを処理する最終的なハンドラーの間に位置します。ルーティングからビジネスロジックへ直接進むのではなく、リクエストは 1 つ以上の middleware 関数を通過します。

流れは次のようになります:

リクエスト
↓
ミドルウェア
↓
ハンドラー

各 middleware 関数は、次のステップに進む前にリクエストを確認、変更、あるいは停止することができます。これにより middleware は、多くのルートに共通する処理を扱ううえで非常に強力になります。

よくある用途には、受信リクエストのログ記録、認証トークンの検証、リクエストデータのチェック、レート制限の適用、エラーを一貫した方法で処理することなどがあります。

Middleware は、チェーン内の次の関数へ制御を渡すこともでき、階層的な処理モデルを作れます。これにより、繰り返しの処理を別に分離できるため、メインのビジネスロジックをきれいに保てます。

Middleware がなければ、これらの処理を各ハンドラー内に重複して書く必要があり、コードは煩雑で保守しにくくなります。Middleware はこのロジックを集約し、アプリケーション全体で一貫性を保ちます。

認証は、システムがビジネスロジックを実行する前に、リクエスト送信者の身元を確認します。このステップがなければ、サーバーはすべてのリクエストを匿名として扱うため、アクセス制御やユーザー固有の動作を適用できません。

この処理は通常、トークン、セッション、または API キーを使って行われます。たとえば、クライアントがリクエストヘッダーに JWT を送信し、サーバーがそれを検証する場合や、Cookie に保存されたセッション ID を含めて、サーバー上のユーザーレコードに対応付ける場合があります。

資格情報が検証されると、システムはユーザー ID、ロール、権限などの識別情報を抽出します。この情報はリクエストコンテキストに付与され、下流のコンポーネントがユーザーが誰であるかに基づいて判断できるようになります。

このステップがパイプラインの早い段階に置かれるのは、システムの多くの部分がこれに依存しているためです。ビジネスロジックでは、権限の確認、ユーザー固有データの取得、識別情報に基づく制限の適用が必要になることがよくあります。

認証に失敗した場合、リクエストは通常 401 Unauthorized レスポンスで直ちに拒否されます。これを早期に処理することで、不正アクセスを防ぎ、先に進むべきでないリクエストに対してリソースを無駄にしないようにできます。

リクエスト検証は、外部入力と内部ロジックの間で門番の役割を果たします。クライアントが正しいデータを送るとは限らないため、サーバーはすべてのリクエストに対してルールを積極的に適用する必要があります。

これらのルールは通常、スキーマを使って定義されます。スキーマは、どのフィールドが必須か、どのデータ型が許可されるか、値をどのように構造化すべきかを指定します。リクエストがスキーマに一致しない場合、以降の処理の前に拒否されます。

たとえば、ユーザー作成リクエストでは、有効な形式の email フィールドが必要になることがあります。フィールドが存在しない、または形式が不正な場合、サーバーは無効なデータを処理しようとせず、エラーを返します。

構造の検証に加えて、検証にはサニタイズが含まれることもよくあります。これにより危険な入力を削除またはエスケープし、インジェクション攻撃や予期しない動作のような問題からシステムを保護します。

早い段階で検証を強制することで、バックエンドシステムは一貫性を保ち、バグを減らし、無効なデータがアプリケーションの深い部分へ広がるのを防げます。

リクエストがルーティング、認証、検証を通過すると、コントローラーに到達します。コントローラーはアプリケーションロジックの入口として機能します。コントローラー自体には複雑なロジックは含まれず、その代わりに次に何を行うべきかを調整します。

コントローラーはビジネスロジックを呼び出します。実際の処理はそこで行われます。ビジネスロジックは、システムがどのように動作するか、つまりデータがどのように処理され、どのルールが適用され、どのアクションが実行されるかを定義します。

たとえば、注文を作成する場合、合計金額の計算、在庫の確認、そして注文をデータベースに保存する、といった複数のステップが必要になることがあります。これらのステップはコントローラーではなく、ビジネスロジックの一部です。

コントローラーとビジネスロジックを分離すると、システムを整理された状態に保ち、保守しやすくなります。コントローラーはリクエストの流れを処理し、ビジネスロジックはアプリケーションのルールに集中します。この分離により、他の部分を壊すことなく、テスト、スケール、変更がしやすくなります。

ビジネスロジックが何を行う必要があるかを判断した後、システムはデータベースとやり取りしてデータを読み書きします。ここで永続状態が管理されます。メモリ上のデータとは異なり、データベースのデータは長期的に保存されます。

アプリケーションは、情報を取得したりレコードを更新したりするために、データベースへクエリを送信します。これらのクエリは、単純な検索から、複数のテーブルや条件を含むより複雑な操作までさまざまです。

多くの場合、操作はトランザクションでまとめられます。トランザクションは、一連の変更がすべて成功するか、すべて失敗するかのどちらかになることを保証します。これは、特に支払い処理や注文処理のような操作で整合性を維持するために重要です。

データベースがクエリを処理すると、その結果がアプリケーションに返されます。その後、ビジネスロジックはこのデータを使って処理を続けるか、クライアントに送信する最終レスポンスを準備します。

すべての処理が完了した後、バックエンドは内部の結果をクライアントに適した形式へ変換する必要があります。通常、これはデータを JSON にシリアライズして、HTTP 経由で送信できるようにすることを意味します。

サーバーは結果を伝えるために HTTP ステータスコードも付与します。これらのコードは、リクエストが成功したのか、クライアント入力の問題で失敗したのか、あるいはサーバー側の問題に遭遇したのかを即座に示します。

例:

HTTP 200 正常
"userId": 42

このステップにより、レスポンスが一貫した契約に従うことが保証されます。クライアントは、サーバー内部を理解しなくても、予測可能な形式とステータスコードに基づいて結果を正しく処理できます。

構築されたレスポンスは、ネットワークを通じて送り返されます。これにより、そのリクエストに対するサーバーの責任は終了し、リクエスト・レスポンスの全体の流れが完了します。