最近、Webアプリの基本を学び直す中で、GETとPOSTの違いについて改めて考える機会がありました。

よくある説明としては、

GETはデータを取得する
POSTはデータを送信する

というものがあります。

最初はこれを見て、正直こう思いました。

じゃあ、全部POSTでよくない？

実際、POSTだけでも画面表示や検索、登録処理を作ることはできそうです。

ただ、調べていくうちに、GETとPOSTの違いは単なる「取得」と「送信」ではなく、ブラウザやキャッシュ、URL共有、セキュリティなど、Webの仕組み全体に関わるものだと分かりました。

この記事では、自分が「POSTだけでよくない？」と思ったところから、GETとPOSTをなぜ使い分けるのかを整理します。

GETは「見るだけ」の処理

まず整理すると、GETはサーバーから情報を取得するときに使うものです。

例えば、ユーザー一覧を表示する場合です。

GET /users

ユーザー詳細を表示する場合はこうです。

GET /users/1

検索もGETがよく使われます。

GET /search?keyword=java

GETのポイントは、基本的にサーバーの状態を変えないことです。

つまり、

一覧を見る
詳細を見る
検索する
ページを表示する

といった処理に向いています。

POSTは「何かを送って、状態を変える」処理

POSTは、サーバーにデータを送って、何かを作成したり変更したりするときに使います。

例えば、新しいユーザーを登録する場合です。

POST /users

ログイン処理もPOSTが使われます。

POST /login

問い合わせフォームの送信もPOSTです。

POST /contact

POSTは、

登録する
送信する
保存する
ログインする
購入する

といった処理に向いています。

では、POSTだけでよくないのか？

ここで自分が疑問に思ったのが、「それならPOSTだけでも作れるのでは？」という点でした。

例えば、全部POSTでこう書くこともできます。

POST /getUsers
POST /createUser
POST /deleteUser

アプリケーションとして動かすことは可能だと思います。

ただ、これは動くとしても、Webの仕組みにうまく乗れていない設計になりそうです。

本来はこう書くと、かなり自然です。

GET    /users
POST   /users
DELETE /users/1

これなら、URLとHTTPメソッドを見るだけで、

GETなら取得
POSTなら作成
DELETEなら削除

と分かります。

ただし、これは単なる「読みやすさ」だけの話ではありません。

GETはキャッシュしやすい

GETは「データを見るだけ」のリクエストなので、ブラウザやCDNがキャッシュしやすいです。

例えば商品一覧ページです。

GET /products

このようなページは、毎回サーバーに問い合わせなくても、キャッシュを使える場合があります。

その結果、

表示が速くなる
サーバー負荷が下がる
CDNと相性がよい

というメリットがあります。

一方、POSTは「何かを送信して処理する」意味があるため、GETほど自然にはキャッシュされません。

検索や一覧表示まで全部POSTにしてしまうと、Webの仕組みを活かしづらくなります。

GETはURLを共有できる

GETでは、検索条件などがURLに入ります。

GET /search?keyword=java&page=2

この場合、URLをコピーすれば、同じ検索結果を他の人に共有できます。

また、ブックマークもできます。

一方、POSTでは送信内容がリクエストボディに入るため、URLだけでは同じ状態を再現しづらくなります。

そのため、

検索結果
絞り込み条件
ページング
詳細ページ

などはGETの方が向いています。

更新処理をGETにすると危険

逆に、データを変更する処理をGETにするのは危険です。

例えば、削除処理をGETで作ったとします。

GET /users/1/delete

これはかなり危ないです。

GETは「見に行くだけ」のリクエストとして扱われます。

そのため、ブラウザのプレビュー機能、クローラー、リンク先チェックツールなどが勝手にアクセスする可能性があります。

もしGETアクセスだけで削除が実行されると、

リンクを開いただけでデータが消えた

という事故が起きる可能性があります。

だから、データを変更する処理はPOST、PUT、PATCH、DELETEなどを使うべきです。

POSTはブラウザも「再送信」に注意してくれる

POST送信後にブラウザで更新すると、

フォームを再送信しますか？

のような警告が出ることがあります。

これは、ブラウザがPOSTを「何かを変更するかもしれないリクエスト」として扱っているからです。

例えば、登録フォームを送信した後にページを更新すると、同じ登録処理がもう一度実行される可能性があります。

GETでは基本的にこのような警告は出ません。

つまり、ブラウザ側も、

GETは何回アクセスしても基本安全
POSTは再実行すると何かが変わるかもしれない

という前提で動いています。

GETはURLに情報が出る

GETでは、パラメータがURLに表示されます。

GET /login?email=test@example.com&password=abc123

これはよくありません。

URLは、

ブラウザ履歴
サーバーログ
アクセスログ
Referer
分析ツール

などに残る可能性があります。

そのため、パスワードや個人情報のような情報をGETで送るべきではありません。

ログインやパスワード変更、問い合わせフォームなどはPOSTを使います。

POST /login

まとめ

最初は、GETとPOSTの違いは「取得」と「送信」くらいの話だと思っていました。

ただ、調べてみるとそれだけではなく、

キャッシュできるか
URLを共有できるか
ブラウザがどう扱うか
意図しないアクセスで事故が起きないか
URLに残してよい情報か

といった、Webの仕組み全体に関わる違いがありました。

ざっくり使い分けるなら、以下のようになります。

やりたいこと	HTTPメソッド
データを見る	GET
検索する	GET
詳細ページを開く	GET
登録する	POST
フォームを送信する	POST
ログインする	POST
更新する	PUT / PATCH
削除する	DELETE

POSTだけでもアプリケーションを作ることはできます。

ただ、GETとPOSTを使い分けることで、ブラウザやHTTPの仕組みに沿った、自然で安全な設計になります。

つまり、GETとPOSTの使い分けは、単なる作法ではなく、Webの仕組みに乗るための設計ルールなのだと理解しました。