Day25 前半のゴール
「“APIがDBの入口になる”イメージを、はっきり持てるようになる」
Day24 で「アプリから MySQL に直接つなぐ」話をしました。
Day25 は、そこにもう一段レイヤーを足して「API 経由でデータを取得・登録する」世界に入ります。
前半のゴールはこうです。
API が何をしているのかを、DBとの関係で説明できる
「ブラウザ → API → DB」という流れを、頭の中でトレースできる
データ取得（GET）と登録（POST）の役割の違いを理解する
ここでは、まだフレームワークの細かい書き方には踏み込みすぎず、
“流れ”と“役割分担”を丁寧にかみ砕きます。
そもそも API って何をしているのか
「“外の世界とDBの間に立つ、門番兼通訳”」
まず、「API とは何か」を、DB目線で言い直してみます。
ブラウザやスマホアプリなど「外の世界」からのリクエストを受け取る
その内容を解釈して、DBに対して SQL を実行する
結果を、JSON などの形式で外の世界に返す
つまり、API は、
外の世界と DB の間に立つ「門番兼通訳」
です。
もし API がなくて、
ブラウザから直接 DB に接続させてしまうとどうなるか。
誰でも好きな SQL を投げられる
認証・認可を制御できない
ビジネスルール（「在庫がマイナスにならない」など）を守れない
つまり、セキュリティも整合性も崩壊します。
だからこそ、
外の世界 → API → DB
というレイヤー構造が、実務ではほぼ必須になります。
「ブラウザ → API → DB」の流れを具体的にイメージする
「ユーザー一覧を表示するだけのシンプルな例で追ってみる」
抽象的な話だけだとつかみにくいので、
「ユーザー一覧を表示する」だけのシンプルな例で流れを追ってみます。
ステップ1：ブラウザが API にリクエストを送る
例えば、フロントエンド（ブラウザ側）が、
JavaScript でこんなコードを書いているとします。
const res = await fetch('https://example.com/api/users');
const users = await res.json();
ブラウザは、
GET /api/users
という HTTP リクエストを、サーバーに送ります。
ステップ2：API がリクエストを受け取る
サーバー側には、Node.js や Python で書かれた API が動いていて、
「/api/users に GET が来たら、この処理を実行する」
というルールを持っています。
その処理の中で、API はこう考えます。
「ユーザー一覧を返せばいいんだな」
→ DB から users テーブルのデータを取ってこよう
ここで、Day24 でやった「アプリから MySQL に接続して SELECT」が登場します。
ステップ3：API が DB からデータを取ってくる
例えば、Node.js なら内部でこんなことをします。
const [rows] = await pool.execute('SELECT id, name FROM users');
Python ならこうです。
cursor.execute('SELECT id, name FROM users')
rows = cursor.fetchall()
ここで rows に入っているのは、
DB から取ってきた「生のデータ」です。
ステップ4：API が JSON にしてブラウザに返す
API は、その rows を JSON に変換して、
HTTP レスポンスとして返します。
Node.js なら（Express を例にすると）こんなイメージです。
res.json(rows);
ブラウザ側は、さっきの
const users = await res.json();
でそれを受け取り、画面に表示します。
この一連の流れを、言葉でまとめるとこうです。
ブラウザが「ユーザー一覧ちょうだい」と API に言う
API が DB に「users テーブルの中身ちょうだい」と言う
DB が結果を返す
API がそれを JSON にしてブラウザに返す
これが「データ取得（GET）」の基本パターンです。
データ取得（GET）と登録（POST）の役割の違い
「読むのが GET、書くのが POST（＋PUT/DELETE）」
HTTP の世界では、
「何をしたいか」によってメソッドを使い分けます。
データを読む → GET
データを新しく作る → POST
データを更新する → PUT / PATCH
データを削除する → DELETE
Day25 前半では、
GET と POST に絞ってイメージを固めます。
GET のイメージ
さっきのユーザー一覧の例が典型です。
GET /api/users
API 側は、
DB から SELECT するだけ
DB の状態は変えない
という約束で動きます。
POST のイメージ
一方、「新しいユーザーを登録したい」ときは、
POST を使います。
POST /api/users
Content-Type: application/json
{
"name": "Alice",
"email": "alice@example.com"
}
ブラウザ（または別のサービス）は、
「この JSON の内容でユーザーを作って」と API にお願いしています。
API 側は、
リクエストボディの JSON を受け取る
バリデーション（必須項目・形式チェック）をする
DB に INSERT する
結果（作られたユーザーの情報など）を JSON で返す
という流れになります。
ユーザー登録APIを頭の中で組み立ててみる
「“受け取る → 確かめる → INSERT → 返す”の4ステップ」
具体的なコードは後半に回すとして、
まずは「何をしないといけないか」を日本語で整理します。
ステップ1：リクエストを受け取る
エンドポイントのイメージはこうです。
POST /api/users
ボディには JSON で、例えばこういうデータが来ます。
{
"name": "Alice",
"email": "alice@example.com",
"password": "secret123"
}
API は、この JSON をパースして、
name / email / password を取り出します。
ステップ2：バリデーションをする
ここがめちゃくちゃ重要です。
name が空じゃないか
email の形式がおかしくないか
password があまりにも短すぎないか
などをチェックします。
さらに、DB側の制約も意識します。
email は UNIQUE 制約がある
→ すでに同じ email が登録されていないか、事前にチェックする
バリデーションに失敗したら、
DB に触る前にエラーを返します。
ステップ3：DB に INSERT する
バリデーションを通過したら、
Day24 でやったように、プレースホルダ付きで INSERT します。
パスワードは、ハッシュ化してから保存する
（これはセキュリティ的に絶対条件）
というのも、API側の責任です。
ステップ4：結果を JSON で返す
INSERT が成功したら、
新しく作られたユーザーの id
name / email（password は返さない）
などを JSON で返します。
例えば、こんなレスポンスです。
{
"id": 123,
"name": "Alice",
"email": "alice@example.com"
}
ここまでが、「ユーザー登録API」の基本的な流れです。
API と DB の“責任分担”を意識する
「DBに任せること・API側でやることを分ける」
API を設計するときに大事なのは、
どこまでを DB に任せて
どこからを API 側でやるか
を意識することです。
DB に任せるべきことの例はこうです。
PRIMARY KEY / UNIQUE / NOT NULL などの制約
外部キー制約（存在しない user_id を orders に入れない など）
トランザクションによる整合性
一方、API 側でやるべきことは、
リクエストの形式チェック（JSON が壊れていないか）
ビジネスルール（パスワードの長さ、メールの形式など）
認証・認可（このユーザーはこの操作をしていいのか）
です。
例えば、「email は UNIQUE 制約があるから、
同じメールで INSERT すると DB 側でエラーになる」
これはこれで正しいです。
でも、ユーザー体験としては、
API 側で事前に「そのメールはすでに使われています」と返した方が親切
なので、API 側で事前チェックを入れる、という選択もあります。
この「どこでチェックするか」を考えられるようになると、
API と DB の設計が一気にレベルアップします。
Day25 前半のまとめ
API は「外の世界（ブラウザや他サービス）と DB の間に立つ門番兼通訳」であり、ブラウザからの GET /api/users のようなリクエストを受けて DB に SELECT ... を投げ、その結果を JSON にして返すのが「データ取得（GET）」、POST /api/users で JSON を受け取り、バリデーションをしてから INSERT ... を実行し、作成されたレコード情報を JSON で返すのが「データ登録（POST）」という基本パターンになる。
このとき、「ブラウザ → API → DB → API → ブラウザ」という流れを頭の中でトレースしつつ、DB に任せるべきこと（制約・トランザクション）と API 側でやるべきこと（入力チェック・ビジネスルール・認証／認可）を意識して分けることで、「API は単なる SQL の薄いラッパー」ではなく、「外部からのリクエストを安全に受け止めて、DB を正しく・安全に使わせるためのレイヤー」として設計できるようになり、Day25 後半ではこれを Node.js / Python の具体的なコード（GET/POSTエンドポイント＋DBアクセス）に落としていく。