はじめに
昨日は CORS（通信がなぜブロックされるか） を解説しました。
今日は一気に API設計の本質である REST API と URL設計 に踏み込みます。
突然ですが、こんな API を見たことはありませんか？
/getUser
/createUser
/deleteUser
/updateUserData
一見「動きそう」に見えますが、これは REST ではありません。
今日のゴールはこれです。
✅ REST API の正体を「言語化」できる
✅ 設計ミスな URL を見抜けるようになる
✅ 現場で通用する RESTful な URL 設計ができるようになる
今日のゴール
・REST が「設計思想」であることを理解する
・URL は「操作」ではなく「資源」を表すと説明できる
・正しい HTTP メソッドの使い分けができる
・ダメな API 設計と良い API 設計の違いが分かる
REST API とは何か？まず結論
REST とは、
✅ Representational State Transfer（状態の表現のやり取り）
✅ 「設計のルール」や「考え方」
✅ 技術でもフレームワークでもない
というのが正確な正体です。
つまり REST API とは、
「Web の仕組みに素直に乗っかった API 設計ルール」
のことです。
REST の最大の特徴はこれだけ覚えれば OK
REST で一番大事なのはこの1文です。
「URL は “名詞”、HTTPメソッドは “動詞”」
悪い例（動詞が URL に入っている）
/getUser
/createUser
/deleteUser
これはすべて NG API 設計 です。
理由は：
・URL に「操作（get / create / delete）」が入っている
・HTTP の動詞（GET / POST / DELETE）と役割が被っている
・API の意味がブレる
正しい RESTful API の例
GET /users → ユーザー一覧取得
GET /users/1 → ユーザー1件取得
POST /users → ユーザー新規作成
PUT /users/1 → ユーザー更新
DELETE /users/1 → ユーザー削除
✅ URL は「users（資源）」だけ
✅ 動き（取得・作成・削除）は HTTPメソッドで表現
これが REST の基本思想です。
REST は「リクエスト・レスポンス」の設計ルール
REST は、まさにこのシリーズのテーマである
リクエストとレスポンスの「正しい使い方」そのもの です。
| 要素 | REST の考え方 |
|---|---|
| URL | 何のデータ（資源）か |
| HTTPメソッド | 何をしたいのか |
| ステータスコード | 結果はどうだったか |
| レスポンス | 状態の表現（JSON） |
初心者がやりがちな REST 設計ミス 3選
URL に動詞を入れる
/createPost
/getPostList
→ ❌ REST ではない
→ ✅ 正解は：
POST /posts
GET /posts
更新なのに POST を使う
POST /users/1/update
→ ❌ 何をしている API なのか不明
→ ✅ 正解は：
PUT /users/1
削除なのに GET を使う
GET /users/1/delete
→ ❌ 絶対にやってはいけない
→ ✅ 正解は：
DELETE /users/1
RESTful な URL 設計の基本ルールまとめ
| 目的 | メソッド | URL |
|---|---|---|
| 一覧取得 | GET | /posts |
| 1件取得 | GET | /posts/1 |
| 新規作成 | POST | /posts |
| 更新 | PUT | /posts/1 |
| 部分更新 | PATCH | /posts/1 |
| 削除 | DELETE | /posts/1 |
✅ この表は 実務で毎日使うレベルの重要表 です。
Laravel で REST API を作るとどうなるか？
Laravel の apiResource を使うと、一瞬で REST API が完成します。
Route::apiResource('posts', PostController::class);
これだけで自動生成される API は：
| メソッド | URL | 処理 |
|---|---|---|
| GET | /api/posts | 一覧 |
| POST | /api/posts | 作成 |
| GET | /api/posts/{id} | 取得 |
| PUT | /api/posts/{id} | 更新 |
| DELETE | /api/posts/{id} | 削除 |
✅ つまり Laravel は最初から REST 思想で設計されている ということです。
フロントエンド（React）から見る REST
React から見るとこうなります。
// 一覧取得
fetch('/api/posts')
// 新規作成
fetch('/api/posts', {
method: 'POST',
body: JSON.stringify(data)
})
// 削除
fetch('/api/posts/1', {
method: 'DELETE'
})
✅ URL は変わらない
✅ メソッドだけが変わる
これが REST の最大の美しさです。
REST を理解すると何が変わるのか？
REST を理解すると、こんな変化が起きます。
✅ API を見ただけで「何ができるか」分かる
✅ フロントとバックエンドの会話が超スムーズになる
✅ 設計レビューで詰まらなくなる
✅ 保守性・拡張性が爆上がりする
今日のまとめ
・REST は技術ではなく 設計思想
・URL は「名詞」、操作は HTTPメソッドで表現する
・/createUser のような URL は NG
・/users + POST / GET / PUT / DELETE が正解
・Laravel の apiResource は REST 設計の完成形
次回 Day9 はいよいよ…
「Laravel で Web API を実装してリクエスト＆レスポンスを実際に動かす」
から、ついに コードが動き始めます。