Route Handler（route.ts）と Server Function は、どう使い分けますか。
分岐点は、HTTPのエンドポイントとして外に見せる必要があるかどうかです。自分の画面からフォームを送るだけなら Server Function で足り、型もそのまま繋がります。
面接官が見ているのは両方の存在意義を説明できるか。
よくある答えと、面談でどう見られるか
- 外部から叩かれる口が要るなら Route Handler、自分の画面からの更新なら Server Function
Webhook やモバイルアプリからの利用が Route Handler の出番です。 - Route Handler の方が伝統的なので、基本はそちらを使う
慣れの問題として理解はできますが、選択の基準にはなりません。自分の画面から送るだけなら、エンドポイント設計の手間が増えるだけです。 - Server Function の方が新しいので、基本はそちらに寄せる
新旧では選びません。外部に口が要るかどうかで分かれます。また Server Function は更新向けで、取得には推奨されていません。 - どちらでも同じことができるので、好みで選んでよい
できることが違います。Route Handler は HTML 以外を返す口として外に見せられますが、Server Function はそうではありません。
面接官は何を見ているか
- 自分の画面からの更新なら Server Function、と言えた
- 外部から叩かれるものは Route Handler、と言えた
- HTTP の口が要るかどうかで分けられている
模範解答
分岐点は「HTTP のエンドポイントとして外に見せる必要があるか」です。
自分のアプリの画面からフォームを送るだけなら Server Function で十分です。エンドポイントを設計する手間が要らず、型もそのまま繋がります。
Route Handler が要るのは、外部から叩かれる口が必要な場合です。Webhook の受け口、モバイルアプリから使う API、HTML 以外（JSON、CSV、画像など）を返す用途がこれにあたります。公式でも Backend for Frontend のパターンとして紹介されています。
なお Route Handler は既定ではキャッシュされません。GET だけは明示的にキャッシュに寄せられますが、それ以外のメソッドはキャッシュされない仕様です。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
データ取得も Server Function でやってはいけませんか。一部しか触れられなかった場合
'use server' と 'use client' は、対になる機能ですか。触れられなかった場合
'use server' と 'use client' は、対になる機能ですか。