Info

post と get の 違い: これだけ知ってると開発がスムーズになる

post と get の 違い: これだけ知ってると開発がスムーズになる
post と get の 違い: これだけ知ってると開発がスムーズになる

Web アプリケーションを作る際に避けて通れない機能が HTTP メソッドです。特に post と get の 違い を正しく理解すると、データ送信先や目的に合わせて適切なリクエストを選べます。この記事では、その基本から応用までを、わかりやすく解説します。

今回紹介するポイントは、データの扱い方を変えるだけでなく、セキュリティやパフォーマンスにまで影響する重要な要素です。初心者はもちろん、プロフェッショナルも再確認したい内容が満載です。

1. 基本的な定義と使い分け

まずは post と get の 違い の核心に迫ります。GET は URL にデータを付けて送信し、主に情報取得に使用される 一方、POST はリクエストボディにデータを隠しつつ送信し、情報を作成または更新する際に使われます。

  • GET: 取得リクエスト(id=123 などのクエリ文字列)
  • POST: 送信データを隠したリクエスト(フォーム、JSON など)
  • レスポンスは共にサーバーから返されるが、GET はキャッシュされやすい

この違いは、外部から見たときの「どんなデータが確認できるか」にも影響します。結果、検索エンジンやブラウザの履歴に残る情報量が変わるのです。

さらに、REST API ではリソースの作成・更新・取得に分けてメソッドを使い分ける設計原則があるため、正しいメソッドの使用は保守性を向上させます。

・GET で送るデータ量はブラウザの履歴に残るので、プライベート情報は送らないようにする。

2. データの送信方法

次に、実際にどのようにデータが送られるかを見ていきましょう。ブラウザは GET リクエストを作るとき、URL 末尾にクエリ文字列を追加します。一方 POST はリクエストヘッダに Content-Type を設定し、ボディ部にデータを載せます。

  1. GET: /api/users?id=1234 のように URL に直接記述
  2. POST: Content-Type: application/json{"id":1234,"name":"John"} をボディに送信
  3. URL の長さに制限がある GET(< 2048 バイトが一般的) は POST の方が大容量データを送れる
  4. ボディの形式は XML, JSON, form-data など多様に選べる

データ量が多い場合や機密性が高い場合は必ず POST を選択するのが基本です。

ブラウザ側の実装では、フォームの method="post" 属性を指定すれば自動的にボディにデータが配置されます。

また、HTTP/2 や HTTP/3 では圧縮が有効になるため、POST の方がオーバーヘッドが低減しやすい傾向があります。

3. URLに表示される情報

GET リクエストでは送信したパラメータが URL のクエリ文字列として可視化されます。一方 POST はリクエストボディに隠れ、URL には表示されません。以下の表で具体的に比較してみましょう。

メソッドURL に表示保護レベル
GETはい (例: /a?b=1)低 (閲覧可能)
POSTいいえ (ボディに格納)高 (解読は難しい)

URL に情報が残るため、検索エンジンにインデックスされやすいという利点もあります。ただし、機密情報を送るには不適切です。

また、GET がキャッシュされる特性は、同じ URL へのリクエストが高速に返されることを意味します。これは高速化に繋がりますが、データが変更されている場合に古い情報が返ってくるリスクがあります。

結論として、検索結果に残したい情報は GET、セキュリティ重視なら POST を選びましょう。

4. セキュリティと情報漏洩のリスク

情報漏洩の観点から見ると、GET と POST の大きな違いは「URL にデータが残るか」です。機密情報は必ず POST で送信し、SSL/TLS (HTTPS) の使用は必須です。以下の箇条書きで主なポイントを整理します。

  • パスワードやトークンは URL に付けない
  • POST の際も HTTPS で暗号化することが安全性を確保
  • ログやキャッシュに残る risk を抑えるため、POST での送信が推奨
  • 受信側は CSRF トークンを検証し、改ざんを防ぐ

さらに、XSS(クロスサイトスクリプティング)対策としては入力値のサニタイズとコンテンツセキュリティポリシー(CSP)の設定が必要です。これらは GET でも POST でも共通ですが、POST の方が情報が隠れているため XSS のリスクは相対的に低く感じられます。

例えば、ユーザー登録フォームでメールアドレスを POST で送ると、ブラウザの履歴に残らず第三者が見ることができません。

また、データベースに保存するリクエストは必ず POST で行い、パラメータをハッシュ化した上で保存するとさらに安全です。

5. 典型的なユースケース

下記によくあるシナリオを上げて、どちらを使うかの判断基準をまとめました。まずは GET の典型的なユースケースです。

  1. 検索結果ページ (例: /search?q=keyword)
  2. ページ遷移時に状態を保持したい場合(クエリパラメータ)
  3. 画像・動画など 1 回だけ取得したいリソース
  4. API の情報取得 (GET /api/users/123)

POST が適しているケースは以下です。

  1. ユーザー登録・ログインフォーム
  2. データの更新、削除操作
  3. ファイルアップロード (multipart/form-data)
  4. 大容量データの送信(JSON, XML)

もし「データ変更か取得か」が曖昧な場合は、まずは REST 原則に従い、データ取得は GET、変更は POST と AWR の初学者向け教材に従うと安全です。

例えば、ユーザーが好きなタグを追加したい場合、POST を使って /api/users/123/tags へ追加することが推奨されます。

6. パフォーマンスとキャッシュの差異

HTTP のキャッシュは GET を前提に設計されているため、同一 URL へのリクエストはブラウザや CDN で高速に返却されます。POST はキャッシュが基本的に無効化されるため、リクエストがその都度完全に送信されます。以下のテーブルで主要ポイントを示します。

項目GETPOST
キャッシュ有効(Expires/ETag)無効(通常)
リクエストサイズURL 長さ制限ありボディで自由
セキュリティ低(URL に表示)高(ボディに隠れ)
用途取得一時的な情報変更・作成永続的情報

キャッシュを有効に活用したい場合は、GET を使用しておくと効果的です。逆に、常に最新の状態を送る必要がある場合は POST で送信しなければリクエストは常にサーバーに届きます。

パフォーマンスを最適化するためには、必要に応じて If-Modified-Since ヘッダを GET で送信し、変更が無ければ 304 Not Modified を返すようにサーバーを構築すると負荷を減らせます。

まとめると、GET は「読み取り専用」な高速リクエスト、POST は「書き込み・大容量」な安全性重視のリクエストというイメージが持てます。開発時にこの違いを意識して選択することで、アプリケーションのセキュリティとUXを向上させられます。

次にこの記事をSNSで共有し、同じ悩みを持つ方に有用な情報を届けましょう。ぜひコメント欄で質問や感想を聞かせてください!