はじめに
Webアプリケーションの開発において、GETとPOSTは最も基本的なHTTPメソッドです。しかし、「いつGETを使い、いつPOSTを使うべきか?」が曖昧なまま実装してしまうと、セキュリティやパフォーマンス、可読性に悪影響を与える可能性があります。
この記事では、GETとPOSTの使い分けの原則や具体的な使用例を整理し、より良いAPI設計・ルーティング設計を行うための指針を紹介します。
🧪 結論:GETは取得、POSTは送信・作成
メソッド | 主な用途 | 特徴 |
---|---|---|
GET |
データの取得 | パラメータはURLに含まれる(クエリ文字列) ブラウザのキャッシュ対象になることがある 何度実行しても結果が変わらない(冪等) |
POST |
データの作成・送信 | パラメータはボディに含まれる キャッシュされない 実行するたびに結果が変わる可能性がある(非冪等) |
1. GETを使うべきケース
- データを「取得するだけ」のとき
- URLをブックマークや共有したいとき
- 検索や一覧表示など「読み取りのみ」の処理を行うとき
GET /users // 全ユーザー一覧の取得
GET /users/123 // 特定ユーザーの取得
GET /search?q=react // クエリを元に検索
2. POSTを使うべきケース
- サーバー側のデータを変更する(新規作成、更新、削除)とき
- 大量のデータや機密データを送信したいとき
- フォーム送信やファイルアップロードを伴うとき
POST /users // ユーザーの新規作成
POST /login // ログイン処理(トークン生成)
POST /contact // 問い合わせ送信
よくある誤解と注意点
❌ GETで副作用のある処理を実行してしまう
GET /deleteUser?id=123 // 削除はGETでやるべきではない
このような設計は、ユーザーがリンクをクリックしただけで重要な操作が実行されてしまい非常に危険です。副作用がある処理には必ずPOST、PUT、DELETEなどを使うべきです。
🛡️ セキュリティ的観点
- GETリクエストはURLにデータが含まれるため、機密情報(パスワードやトークン)は絶対に含めてはいけません。
- POSTはCSRF対策が必要になる場合があります。フォーム送信時はトークンを付けるなどの対応が必要です。
📦 まとめ
シチュエーション | 推奨メソッド |
---|---|
一覧表示・検索 | GET |
詳細表示 | GET |
新規登録 | POST |
ログイン | POST |
削除・更新など副作用あり | POST(またはPUT/DELETE) |
補足: 冪等性(べきとうせい)とは?
同じ操作を何度繰り返しても、結果が変わらない性質のことです。
✅ 冪等な操作(GET)
GET /users/123
- このリクエストを何回送っても、「IDが123のユーザー情報」が返ってくるだけ。
- サーバーのデータは変わらない → 冪等
❌ 非冪等な操作(POST)
POST /users {"name": "Taro"}
- 実行するたびに新しいユーザーが作成される。
- 毎回サーバーの状態が変わる → 非冪等
📘 なぜ冪等性が重要?
- APIを安全に再実行できるかの判断基準になります。
- ネットワークエラーでリトライが発生したとき、冪等であれば安心して再送できる。
- REST APIの設計原則でも「GET/PUT/DELETEは冪等であるべき」とされています。
📝 補足:HTTPメソッドと冪等性
メソッド | 冪等性 |
---|---|
GET | ✅ あり(データ取得) |
POST | ❌ なし(新規作成など) |
PUT | ✅ あり(上書き) |
DELETE | ✅ あり(すでに削除済みでもOKとする設計なら) |
何度同じリクエストを送っても結果(サーバー側の状態)が変わらないことが「冪等性」のポイントです。開発者は、特にAPIを設計するときにこの概念を意識すると、安全で再利用性の高い設計ができます。
おわりに
GETとPOSTの使い分けはWebアプリの設計の基本ですが、守られていないケースも多く見受けられます。この記事が、エンドポイント設計をより適切に行うための助けになれば幸いです。