Web関連の開発をしていると必ずと言っていい程「GET」と「POST」という言葉が出てくるかと思います。
今回はHTTPの「GET」と「POST」の違いについてまとめてみます。
目次
基本事項として

「GET」も「POST」もクライアントPCなどからサーバーに送信するデータ「リクエストパラメーター」を送信する方式となります。
Web開発初心者の方だと「GET」という言葉からサーバーからデータを取得するのかなあと勘違い(私だけ?)してしまうかもしれませんが、どちらも入力フォームのデータをサーバへリクエスト送信する際に使用します。基本的に以下の特徴を踏まえて、用途別に応じて適切に使い分ける必要があります。
GET送信の特徴
- HTMLの<form>タグの属性に「<form method=”get”>」のように指定して送信します。
- 「https://write-remember.com?id=abc&data1=123」のようにHTTPリクエストヘッダへリクエストパラメータが付与されます。
URLの後の「?」がgetパラメータ開始という意味となり、パラメータが複数ある場合は「&」で区切って指定されます。 - データをリクエストURLの末尾に付与して送信する方式となるため、Webサーバやプロキシサーバのアクセスログなどに残ることになります。
- 他の人がURLを見ると、入力したデータが丸見えになってしまうリスクがあるので、ログイン画面などではIDやパスワードが他者から丸見えになるのでGET送信は使用するべきではありません。
- URLの後に付与するのでデータ量(文字数)に制限が掛かる。(Internet Explorer のURLに使用できる最大文字数は最大2,048 文字)
- GETはHTTPヘッダ情報に含まれるため、簡単に取得することが可能。
- テキストデータのみ送信可能。
POST送信の特徴
- HTMLの<form>タグの属性に「<form method=”post”>」のように指定して送信します。
- HTTPのBODY部にリクエストパラメータが格納されます。
- GETのようにURLの末尾にパラメータは付与されません。
- 個人情報などの重要な情報や、データ量が多い場合はPOST送信を使用します。
- POSTはBODY部分(form)に含まれるため、取得がちょっと面倒。
- テキスト、バイナリどちらでも送信可能。
- POST送信後にブラウザの戻るボタン押下で有効期間切れが発生する場合がある。
- GETのように容易に他者からパラメータはわかりませんが、安全に個人情報を送信する際はPOSTに加えて暗号化などの処置を施す必要があります。
📌 補足
✔️ 1. 意味と利用目的を正確に理解する
- HTTP メソッドとしての GET / POST は「データを送信」する以外に、Web サーバーに対して どのような操作を要求するか を表す規約です。
- GET:リソース(データ)の「取得」を要求することが主目的。副作用がないのが理想。
- POST:リソースの「生成・変更・処理」など、状態を変更する操作に使われる。
※ 実際のフォームでは必ずしもこの原則に従わないケースもありますが、Web API ではこの意味が重要になります。
🛠 2. HTTP の他のメソッドと比較する
| メソッド | 用途 | 例 |
|---|---|---|
| GET | データ取得 | ページ閲覧、検索 |
| POST | データ送信(生成・処理) | フォーム送信、ファイルアップロード |
| PUT | データの更新 | リソースの完全置換 |
| PATCH | データの部分更新 | 一部だけ更新 |
| DELETE | データ削除 | 削除処理 |
API や REST 設計では GET / POST 以外もよく使われます。
🔐 3. セキュリティ面での注意
パラメータが見える問題(GET)
- GET は Query String(URL の ?以降)にデータを載せるため、
- ブラウザの履歴に残る
- 共有すると他人に見られる
- ログに残る
というリスクがあります。
暗号化の必要性(POST)
- POST は Body に入るとはいえ 暗号化されないと情報は見られる可能性 があるため、重要情報送信時は必ず HTTPS を使います(SSL/TLS)。
→ HTTPS を使うことで ネットワーク経路上で盗聴されにくく なります。
📏 4. GET / POST の制限とパフォーマンス
GET の制約
- URL 長さはブラウザ/サーバー依存ですが、一般に 約 2048 文字まで とされ多量のデータ送信には不向きです。
POST はサイズ大きくても OK
- POST は Body 部に入るため大きいデータにも対応しやすいです。
さらに画像やバイナリデータの送信にも対応します(multipart/form-data 形式)。
🧠 5. キャッシュと再送の挙動が違う
GET(キャッシュされがち)
- GET はキャッシュされる可能性があります(ブラウザ/中間キャッシュ)。
データを取得し直したい場合はキャッシュ制御ヘッダが重要。
POST(原則キャッシュしない)
- POST は一般的に 同じ内容の再送信が行われると副作用が起こる可能性 があるため、キャッシュされません。
🔄 6. ブラウザの「戻る」ボタンと再送
- POST を送信した後、「戻る」や再読込をすると POST data の再送信確認 が出るのは副作用を防ぐためです。
- GET は再読込しても再送信扱いになりません。
📑 7. Web API での実践的な使い分け
API 設計の基本ルール
- GET → データ取得のみ
- POST → 新規データ生成
- PUT / PATCH → データ更新
- DELETE → データ削除
こうした設計ルールを「RESTful API」と呼びます。
HTML フォームばかりでなく、現代の API / SPA 開発にも重要な考え方です。
✅ まとめ
| 特徴 | GET | POST |
|---|---|---|
| パラメータ位置 | URL の後ろ | Body |
| データ量制限 | 小さい | 大きい OK |
| セキュリティ | 見えやすい | 見えないが暗号化必要 |
| バイナリ送信 | ✕ | ○ |
| 副作用 | ない方がいい | あり |



