バックエンドのちょっと詳しいアーキ的な仕組み（API・データ・認証）
API・データ・認証を一緒に見る
バックエンドを理解するとき、APIだけ、データベースだけ、と個別に覚えると処理の流れが切れやすくなります。ここでは、リクエストとレスポンス、データの整合性、認証・認可を同じ処理の中で追います。
細かな例外や厳密な定義は一部省略しています。実際の設計では、利用するプロトコルやフレームワークの公式ドキュメントも確認してください。
先に結論
- バックエンドは、決まった形（API）でリクエストを受け取り、決まった形で応答します。
- 応答には「データ」と「結果を表す数字（ステータスコード）」が付きます。
- 「誰か（認証）」と「何をしてよいか（認可）」の判断は、必ずサーバー側で行います。
バックエンドを3つの視点で追う
前々回で「バックエンドは受け付ける・判断する・保存するプログラム」、前回で「言語・フレームワーク・データベース・実行環境の4部品」を見てきました。
ここでは、バックエンドが実際にどうやり取りし、どう正しさを守るのかを、3つの角度から確認します。
- どんな形でリクエストを受け、応答するのか（API）
- データの正しさをどう守るのか（トランザクション）
- 「誰が・何をしてよいか」をどう確かめるのか（認証・認可）
フロントエンド側の「レンダリングとSPA/MPA」に対応する、バックエンド側の“もう一段詳しい仕組み”の回です。
API・データ・認証の3つの視点
1. API：決まった「窓口」でやり取りする
フロントは「このデータをください」「これを保存して」と、バックエンドのAPI（決まった窓口）に要求します。
このやり取りは、主に次の2つの組み合わせで表されます。
- HTTPメソッド（何をしたいか＝動詞）
- エンドポイント（対象は何か＝URL）
代表的なメソッドはこの4つです。
| メソッド | 役割 | イメージ |
|---|---|---|
| GET | 取得する | 見る |
| POST | 新規に作成する | 追加する |
| PUT / PATCH | 更新する | 書き換える |
| DELETE | 削除する | 消す |
たとえば「注文一覧を見る」なら GET /orders、「注文を1件追加する」なら POST /orders、というイメージです。
バックエンドは要求を処理し、データ（JSON形式が主流） と、次に説明するステータスコードを返します。
2. HTTPステータスコード：結果を数字で返す
バックエンドは、処理の結果を3桁の数字（ステータスコード）で返します。先頭の数字で、ざっくり意味が分かれます。
| 区分 | ざっくりの意味 | よく見る例 |
|---|---|---|
| 2xx | 成功 | 200 OK、201 Created |
| 3xx | リダイレクト（移動した） | 301、302、304 |
| 4xx | リクエスト側の問題 | 400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found |
| 5xx | サーバー側の問題 | 500 Internal Server Error、503 Service Unavailable |
覚え方としては、「2xx=成功、3xx=移動、4xx=こちら（頼み方）のせい、5xx=サーバーのせい」とざっくり掴んでおくと、トラブル時の切り分けがぐっと速くなります。
3. データ整合性：トランザクションで「全部か、なしか」
保存の場面では、「途中で失敗されると困る」処理があります。
典型例が送金です。「Aさんから引く」と「Bさんへ足す」がセットで、片方だけ実行されたら大問題です。
そこで使うのがトランザクションという仕組みです。
- ひとまとまりの処理を、「全部成功」か「全部なかったことにする（ロールバック）」 のどちらかに保証します。
- 途中でエラーが起きても、中途半端な状態を残しません。
複数の人が同時に操作する、途中で失敗しうる、といった状況でデータの正しさを守るのは、フロントではなくバックエンド（とデータベース）の重要な仕事です。
APIのリクエストとレスポンス（図）
認証と認可：「誰か」と「何をしてよいか」
セキュリティの話でよく混同されるのが、認証と認可です。言葉の意味が違います。
| 用語 | 何を確かめるか | 例 |
|---|---|---|
| 認証（Authentication） | 「あなたは誰か」 | ログインして本人確認する |
| 認可（Authorization） | 「あなたは何をしてよいか」 | 注文削除の権限があるか確認する |
たとえば「ログインはできる（認証OK）が、他人の注文は削除できない（認可NG）」というように、2つは別物です。
そして重要なのは、この判断は必ずバックエンド側で行うという点です。
フロントのコードはユーザーが書き換えて送れるため、「ログイン済みかどうか」「その操作をしてよいか」をフロントだけで判断すると、簡単に破られてしまいます。前々回・フロント編で触れた「秘密や最終判断をフロントに置けない」という話は、ここにつながります。
一般的な流れとしては、ログインに成功するとトークン（本人であることの証明書のようなもの）が発行され、以降のリクエストにそれを添えて送り、サーバーが毎回それを確認します。仕組みの名前（トークン、セッションなど）は、いまは知っておく程度で十分です。
認証つきリクエストの流れ（図）
認証・認可・入力確認は、APIの入口から処理までを通して行います。確認の関門として見ると、役割を追いやすくなります。
勘違いしやすい解釈
-
「404が出たら必ずサーバーの不具合」ではありません。
4xxはリクエスト側（URLの間違いなど）を示すことが多く、サーバーの故障は5xxです。まず数字の先頭で切り分けます。 -
「ログインできれば何でもできる」ではありません。
認証（誰か）と認可（何をしてよいか）は別です。ログイン済みでも、権限がなければ実行は拒否されます。 -
「HTTPSで通信していればデータは絶対に安全」ではありません。
HTTPSは通信の“経路”を守りますが、「その操作をしてよいか」の判断はサーバー側で別途必要です。通信の暗号化と、権限の確認は別の話です。 -
「APIは特別で難しい技術」ではありません。
APIは「決まった形の窓口」のことです。メソッドとURLで要求し、データとステータスコードで返る、というルールが決まっているだけです。
設計や不具合調査で意識すること
- 不具合調査では、まずステータスコードを見ます。4xxならリクエストの作り方、5xxならサーバー側、と当たりをつけられます。
| ステータスコード | よくある意味 | まず確認すること |
|---|---|---|
| 200 | 正常に成功 | 返ってきたデータの中身が期待どおりか |
| 201 | 作成に成功 | 作成されたIDやLocationヘッダが返っているか |
| 400 | リクエスト不正 | 必須パラメータ不足・型違い・JSON形式崩れがないか |
| 401 | 認証エラー | トークン期限切れ・未ログイン状態ではないか |
| 403 | 権限不足 | ログイン済みでも権限ロールが不足していないか |
| 404 | 対象なし | URLの打ち間違い・ID誤り・ルーティング設定漏れがないか |
| 500 | サーバー内部エラー | サーバーログに例外やスタックトレースが出ていないか |
| 503 | 一時的に利用不可 | メンテナンス中・過負荷・依存先停止がないか |
- ブラウザの開発者ツールのNetworkタブで、実際のメソッド・URL・ステータス・レスポンスの中身を確認する習慣をつけると、フロントとバックのどちらの問題かを切り分けやすくなります。
- 認証まわりは、自前でゼロから作るより、フレームワークや実績のある仕組み・ライブラリに任せるのが安全です。セキュリティは「自作しない」判断も大切です。
まとめ
- バックエンドは、API（メソッド＋URL）で要求を受け、データとステータスコードで応答します。
- ステータスコードは「2xx成功・3xx移動・4xxこちらのせい・5xxサーバーのせい」でざっくり分かれます。
- データの正しさはトランザクション（全部か、なしか）で守られます。
- 「誰か（認証）」と「何をしてよいか（認可）」は、必ずサーバー側で判断します。
- 次回は、ここまでのフロント編・バック編をつなげ、1つの操作が全体をどう往復するのかを通しで見ていきます。
この理解のあとに進めていけること
- 普段使うWEBサービスで操作をしながら、ブラウザの開発者ツール（F12）のNetworkタブを開き、飛んでいるリクエストのメソッドと、返ってくるステータスコードを見てみます。「いまのは GET で 200 だな」と読めるようになると、裏側の動きが一気に身近になります。