前回の続き——ランタイムの一歩先へ
前回のJ-03では、サーバーを動かす土台であるNode.jsランタイムを見ました。ランタイムはポートで待ち受け、リクエストが来たら関数を呼ぶ、というところまで確認しました。今回はその一歩先、届いたリクエストを「どの関数に渡すか」を決める仕組みを扱います。ここが分かると、サーバーのコードが一気に読めるようになります。
このスライドのポイント
- J-03: Node.jsランタイムがポートで待ち受け、リクエストが来たら関数を呼ぶ、まで確認した
- 今回の役割: その「どの関数を呼ぶか」を決める仕組みを扱う
- ここが読めると、サーバーのコードが地図付きで読めるようになる
定義——ルートとハンドラー
定義から入ります。ルートとは、「このメソッドとこのパスの組み合わせには、この処理」という対応規則のことです。メソッドはD-05で、パスはD-02で学んだとおりです。そしてハンドラーとは、その処理の本体となる関数です。I-06で扱ったイベントハンドラーのサーバー版で、画面の操作イベントの代わりにリクエストを受け取ります。サーバーの本体は、このルート表とハンドラー群の集まりだと言ってよいでしょう。
このスライドのポイント
- ルート = 「このメソッド（D-05）とこのパス（D-02）の組には、この処理」という対応規則
- ハンドラー = その処理の本体となる関数
- ハンドラーはI-06のイベントハンドラーのサーバー版（イベントの代わりにリクエストを受ける）
- サーバーの本体は「ルート表＋ハンドラー群」と言ってよい
なぜ必要か——コードの地図がないと読めない
この仕組みを知らないとどうなるでしょうか。AIが生成したサーバーコードを開いても、どこから読めばよいのか分からず、全体像が掴めません。またD-05で、同じURLでもメソッドが違えば別の処理になる、と学びました。その分かれ目がコードのどこにあるのかも読み取れません。ルートとハンドラーという地図があれば、長いコードでも迷わず目的の処理にたどり着けます。
このスライドのポイント
- 知らないと: AIが生成したサーバーコードの全体像が掴めない
- D-05で見た「同じURLでもメソッド違いで別処理」が、コードのどこで分かれるか読めない
- ルートとハンドラーは、長いコードの中で目的の処理へたどり着く地図になる
構造——ルート表がサーバーの設計図
構造を見ます。ルートは、一覧の表として捉えると分かりやすいです。たとえばGETで/api/expensesが来たら一覧を返すハンドラーへ、POSTで同じパスが来たら新規作成のハンドラーへ、というように行が並びます。D-05で作ったメソッドとパスの対応表を覚えているでしょうか。あの表が、そのままサーバーの設計図になります。設計図とコードが1対1で対応しているわけです。
このスライドのポイント
- ルートは一覧の表として捉える
- 例: GET /api/expenses → 一覧ハンドラー ／ POST /api/expenses → 作成ハンドラー
- D-05で作ったメソッド×パスの対応表が、そのままサーバーの設計図になる
具体例——フロントが呼ぶ相手はこの表
具体例で確かめます。D-05では、タスク管理アプリのAPIを一覧にしました。一覧の取得、1件の追加、更新、削除、といった操作です。あの一覧は、そのままこのサーバーのルート定義になります。そしてI-10で学んだとおり、フロントエンドがデータを求めて呼び出す相手は、まさにこのルート表です。画面側とサーバー側が、この表を挟んで向き合っている構図が見えてきます。
このスライドのポイント
- D-05のタスク管理アプリのAPI一覧（一覧・追加・更新・削除）が、そのままルート定義になる
- I-10のフロントエンドがデータを求めて呼び出す相手は、このルート表
- 画面側とサーバー側が、この表を挟んで向き合っている
技術サンプルカード——ルート定義とハンドラー骨子
サンプルを見ます。上の2行がルート定義です。GETで/api/expensesが来たらlistExpensesという関数へ、POSTならcreateExpenseへ振り分けています。下のcreateExpenseがハンドラーの本体です。中身のコメントに注目してください。検証、業務ルール、保存依頼、という順に処理が並び、最後に201を返しています。この一つひとつが、これから先の講義で詳しく扱う舞台です。なお書き方はサーバーの枠組みによって変わります。
混同しやすい概念——ルートとハンドラー
混同しやすい2つを整理します。ルートとハンドラーは、セットで語られるため区別が曖昧になりがちです。ルートは「どのリクエストをどの関数へ送るか」という対応規則、いわば案内表です。ハンドラーは、送り届けられた先で実際に仕事をする処理の本体です。表と中身、と覚えてください。案内表だけあっても中身がなければ動かず、中身だけあっても案内表がなければ呼ばれません。
このスライドのポイント
- ルート = 「どのリクエストをどの関数へ送るか」の対応規則（案内表）
- ハンドラー = 送り届けられた先で実際に仕事をする処理の本体（中身）
- 「表と中身」で覚える
バイブコーディングでの確認点——変わったルートを聞く
バイブコーディングでの確認点です。AIにサーバーの機能追加を頼んだときは、まず「追加または変更されたルートはどれですか」と聞いてください。A-04で、生成のたびに差分を確認する習慣を学びました。これはそのサーバー版の型です。ルート単位で差分を捉えると、意図しない振り分けの変更や、思わぬ処理の追加に早く気づけます。全体を読み返す前に、変わった行だけを的確に確認できます。
このスライドのポイント
- AIにサーバーの機能追加を頼んだら、まず「追加・変更されたルートはどれですか」と聞く
- これはA-04で学んだ差分確認の、サーバー版の型
- ルート単位で差分を捉えると、意図しない振り分けの変更に早く気づける
まとめと次回
最後に一問一答です。リクエストを処理する関数を、何と呼ぶでしょうか。……答えは、ハンドラーです。ルートという対応規則が呼び出す、処理の本体でしたね。30秒まとめです。サーバーの本体は、メソッドとパスの対応規則であるルートと、その処理本体であるハンドラーの集まりです。この地図があれば、AIのコードも対応表として読めます。次回は、ハンドラーの前後に挟む共通処理、ミドルウェアへ進みます。関連資料は「API連携 超入門」「Webhook入門」です。
このスライドのポイント
- 一問一答: リクエストを処理する関数を何と呼ぶ？ → ハンドラー
- 30秒まとめ: サーバーの本体は「ルート（対応規則）＋ハンドラー（処理本体）」の集まり
- 次回: ハンドラーの前後に挟む共通処理、ミドルウェア（J-05）へ
- 関連資料: 「API連携 超入門」「Webhook入門」
