GETとPOSTは通信方法が異なる！

フォームデータのやり取りをした場合、GETとPOSTはどちらが優れているのか？

GETメソッドはPOSTより劣る！？

"GETは転送量に制限を受けるため、POSTより劣る"という意見がある。
イコール"POSTは制限がないため、GETより優れている！"という見解。

しかしGETで使用するURLの長さについて規定しているRFC2616規定では「HTTPはプロトコルとしてURIの長さを制限しない」としている。
URIとは、インターネット上に存在する情報の場所を指し示す言葉でURLはURIの機能の一部とみなせる。

なぜ制限がないのに冒頭のような話がたびたび登場するのか？
実は制限がかかっているのはHTTPの仕様ではなく、WEBサーバーもしくはクライアントであるWEBブラウザの仕様である。

代表的なWEBサーバーであるApatchは、初期設定8190バイトまでのURIを処理できる。
この制限はApatchの設定変更で更に大きくできる。

ちなみにサーバーが処理できる上限を超えたURIを受け取った場合、
「414 Request-URI Tool Long」というレスポンスを返す。

しかし一般的なWEBサイトで414レスポンスを受け取ることはまずない。
論文のような長いテキストをURLで送信する特別な場合でない限り、GETを使ってもデータ長の問題で動かないことはない。

GETは、POSTと違ってブラウザにフォームデータがそのまま表示されるため、安全面でPOSTが優れているという見解もおかしい。なぜなら、TCPモニタリングソフトを利用すれば、メッセージボディも含めて送信内容はキャプチャできる。

もし「安全性」を言及するのであれば、SSL通信を使うべきで、POSTならば安全という理由にはならない。確かに誰が使うか不明の端末で、ブックマーク表示時や履歴表示の際にURL欄にフォームデータが表示されない点では若干安全ではあるが…

一方、フォームデータが表示された方がいい場面もある。
例えば、地図の位置情報や不動産の物件検索結果などをメールで送信する場合、GETを用いてURLにフォームデータが含まれていることで利便性が上がる。

このように他者に情報を伝えることを考えれば、GETによる表示は利便性が高いことがわかる。

一方POSTで送信すれば、閲覧者側でデータを改ざんしたり、ブラウザのURL欄からフォームを経由せずに直接サーバーサイドのプログラムを呼び出したりできないメリットはある。

複数ページにわたってフォームデータを持ち続けているようなケースは、GETの場合「戻る」ボタンを使っても問題は起きないが、POSTの場合、「データを送信しますか？」というメッセージが表示される。

アンケートサイトのように、数ページを遷移して進む構成のサイトでは「途中で戻れません」と書かれていることが多いが、これはPOSTを使っているためだ。

つまりGETとPOSTは一長一短であり、「適材適所」というのが答えだ。

最後に…
もしどちらかが「優れている」のであれば、劣っている方は淘汰されているはず。
両者に生き残っているということは優劣はないということである。