Frontend ↔ Server Map

フロント↔サーバー対応表

サーバーサイドは、まったくの未知の世界ではありません。フロントエンドで身につけた考え方の多くは、そのままサーバー側にも対応するものがあります。ここでは両者を並べて、「知っていることの延長」としてAPI設計を捉えられるように整理しました。気になった行があれば、右端のリンクから詳しい記事へ進んでみてください。

この表の読み方

左が「共通する関心事」、真ん中が「フロントでの現れ方」、右が「サーバーでの現れ方」です。多くの行に共通するのは、フロントは体験のため・サーバーは正しさと安全のために同じことをしている、という視点です。同じ作業でも「目的」がずれることを意識すると、役割分担がすっきり見えてきます。

データを読む・書く

フロントは「呼ぶ側」、サーバーは「応える側」です。同じ1回のやり取りを、送る側と受ける側の両面から見てみましょう。

共通する関心事	フロントでは	サーバーでは	深掘り
データを取得する	fetch / axios / useSWR で API を呼び、返ってきた JSON を state に入れる	エンドポイントを定義し、DB に問い合わせ、必要な形へ整えて返す	HTTPメッセージの構造
データを更新する	フォーム送信で POST / PATCH を投げ、成功したら画面を再描画する	入力を検証し、DB を書き換え、結果のステータスとボディを返す	CRUDとメソッドの対応
「何をするか」の指定	メソッド（GET / POST / …）と URL を組み立てて渡す	メソッド × パスでハンドラを振り分け、意味どおりに処理する	HTTPメソッドと安全性・冪等性
送るデータの形	オブジェクトを JSON.stringify してボディに載せる	ボディをパースし、型・必須・範囲を検証してから受け入れる	入力バリデーションの基本

状態と永続化

フロントの状態は「今この画面だけ・再読込で消える」ものが基本です。サーバーの状態は「プロセスやユーザーをまたいで残る」もの。この寿命の違いが設計の分かれ目になります。

共通する関心事	フロントでは	サーバーでは	深掘り
状態を持つ	useState / ストア（Redux・Zustand など）。メモリ上・再読込で消える	DB / ファイルに保存。プロセス再起動をまたいでも残る	リレーショナルDBの基礎
一時的なキャッシュ	React Query / SWR のキャッシュ。同じデータの再取得を省く	Cache-Control ヘッダーで「どれだけ再利用してよいか」を宣言する	主要なHTTPヘッダー
ログイン状態	トークンを localStorage / cookie に保持し、リクエストに添える	トークン／セッションを検証し、「誰からのリクエストか」を確定する	認証方式（セッション/トークン/JWT/APIキー）

ルーティングとエンドポイント

どちらも「URL を見て処理を振り分ける」点は同じです。フロントは画面を、サーバーはリソースへの操作を割り当てます。

共通する関心事	フロントでは	サーバーでは	深掘り
URL で分岐する	React Router / Next.js のルーティングで、パスに対応する画面を表示	メソッド × パスに対応するハンドラ（エンドポイント）を実行	RESTの考え方（リソース指向）
URL の設計	/users/:id のように画面の階層をパスで表す	/users/:id のようにリソースの階層を名詞で表す（動詞は入れない）	URL設計と命名
クエリ文字列	?tab=profile で画面の細かい状態を URL に持たせる	?status=active&sort=-created_at で絞り込み・並べ替えを受け取る	検索・フィルタ・ソート・ページネーションのクエリ設計

入力の検証

フロントの検証は「親切」、サーバーの検証は「防御」です。フロントでどれだけ丁寧にチェックしても、サーバーは必ず自分でもう一度確かめます。

共通する関心事	フロントでは	サーバーでは	深掘り
入力チェックの目的	ユーザーへの即時フィードバック（体験を良くするため）	不正・悪意ある入力を境界で止める（データを守るため）	信頼境界と防御的設計
チェックを飛ばされたら	JS を無効化・改ざんすればいくらでも回避できる（信用できない）	ここが最後の砦。フロントの検証は「あって当然、無くても困らない」前提	入力バリデーションの基本
エラーの伝え方	フィールドの下に赤字で「メールアドレスの形式が不正です」	422 とフィールド単位のエラー配列を、機械可読な形で返す	バリデーションエラーの返し方（422・フィールド単位）

エラーの扱い

フロントは「画面にどう見せるか」、サーバーは「何が起きたかを正しいコードと形で伝えるか」を担います。

共通する関心事	フロントでは	サーバーでは	深掘り
失敗の表現	try/catch でエラーを捕まえ、トーストやダイアログで知らせる	ステータスコードで種類を、ボディで詳細を伝える	ステータスコードの選び方
エラーボディの形	error.message を読んで表示するだけになりがち	Problem Details（RFC 9457）など一貫した形で、type・title・detail を返す	エラーレスポンスの形（Problem Details / RFC 9457）
分岐に使う情報	ステータスコードやエラーコードを見て画面の出し分けを決める	契約として決めた機械可読なコード体系を、API 全体で揃えて返す	エラー設計の一貫性

認証と認可

フロントは「誰かの証（トークン）を預かって運ぶ」係、サーバーは「その証を確かめ、何をしてよいかを判定する」係です。security の核心はサーバー側にあります。

共通する関心事	フロントでは	サーバーでは	深掘り
「誰か」を確かめる（認証）	ログインフォーム → トークンを受け取り保存 → 以降のリクエストに添える	トークン／セッションを検証し、本人を特定する。失敗は 401	認証と認可の違い（401と403）
「してよいか」を判定する（認可）	ロールに応じてボタンやメニューを出し分ける（見た目の制御）	ロール・所有権を必ずサーバーで判定する。違反は 403	認可モデル（RBAC・ABAC・所有権チェック）
他人のデータへのアクセス	URL の id を書き換えれば、別の id のリクエストは簡単に送れてしまう	「そのリソースを本当に見てよい人か」を毎回確認する（IDOR 対策）	IDOR（安全でない直接オブジェクト参照）

一覧・検索・ページネーション

「たくさんのデータを、少しずつ・条件つきで見せる」という同じ課題に、フロントとサーバーが両側から取り組みます。

共通する関心事	フロントでは	サーバーでは	深掘り
大量データの表示	無限スクロール・ページ送り UI を組む	offset / cursor でページ単位に区切って返す	ページネーションのレスポンス設計
絞り込み・並べ替え	フィルタ UI の状態を URL のクエリに反映する	クエリを検証し、安全に WHERE / ORDER BY へ落とす	検索・フィルタ・ソート・ページネーションのクエリ設計
「速さ」の担保	取得回数を減らす（React Query のキャッシュ・重複排除）	インデックスを張り、N+1 を避けて 1〜2 クエリに畳む	N+1問題の解消

型・契約・返す中身

フロントとサーバーの間で交わす「約束（契約）」の話です。何を返し、何を返さないか——ここを曖昧にすると、事故や手戻りが生まれます。

共通する関心事	フロントでは	サーバーでは	深掘り
返すデータの形	API の型（TypeScript の interface）を信じて画面を組む	DB の行をそのまま返さず、返してよい形へ意図的に変換する	レスポンスボディ設計の原則
「出してよい列」の判断	使わないフィールドは無視すればいい、と考えがち	ホワイトリストで能動的に選ぶ。使わない列も送れば攻撃者が読む	含める/除外するフィールドの判断
機密の扱い	画面に出さなければ大丈夫、という誤解	password_hash・内部メモなどは、そもそもレスポンスに含めない	機密フィールドの扱い
まとめて書き込む	「注文する」ボタン1つ = 複数テーブルへの書き込み、と意識しにくい	注文・明細・在庫・決済を1トランザクションで束ね、全部成功か全部取消	複数更新の原子性

こうして並べてみると、サーバーサイドの多くは「フロントで無意識にやっていたことを、今度は責任を持って引き受ける側に回る」ことだと分かります。とくに検証・認可・返す中身の取捨選択は、フロントでは省略できてもサーバーでは省略できません。ここが本サイトの API ドリルでくり返し問われる勘所です。まずは1章、気になったテーマから読み進めてみましょう。