POST (HTTP)

World Wide WebとHTTPは、POSTやGET、さらにはPUT、DELETEなどの多数のリクエストメソッド（「動詞」）に基づいている。通常、ウェブブラウザはGETとPOSTのみを使用するが、RESTfulなオンラインアプリケーションソフトウェアはその他の多くのメソッドも活用する。HTTPメソッドの範囲内におけるPOSTの役割は、新しいデータエンティティの表現をサーバに送信し、URIによって識別されるリソースの新しい従属物として保存させることである^[1]。例えば、http://example.com/customersというURIに対して、POSTリクエストは新しい顧客を表すことが期待され、それぞれに名前、住所、連絡先などが含まれる。初期のウェブサイト設計者は、2つの重要な点でこの本来の概念から逸脱していた。第一に、POSTデータが保存される従属的なウェブリソースをURIがテキストで記述しなければならない技術的な理由はない。実際、何らかの工夫をしない限り、URIの最後の部分はhttp://example.com/applicationform.phpのように、ウェブアプリケーションの処理ページとその技術を記述する可能性が高くなる。第二に、ほとんどのウェブブラウザはGETまたはPOSTしか使用できないという当然の制限があるため、設計者は既存のレコードの変更や削除など、他の多くのデータ送信およびデータ管理タスクを実行するためにPOSTを別の目的に再利用する必要性を感じていた^[要出典]。

第一の点を改善しようとする一部の有力な執筆者による取り組みは、早くも1998年に始まった^[2]。Ruby on Railsなどのウェブアプリケーションフレームワークは、設計者がユーザーにセマンティックURLを提供することを容易にしている。第二の点に関しては、クライアントサイドスクリプトを使用したり、スタンドアロンアプリを作成したりすることで、関連する場面で他のHTTPメソッドを利用することが可能である^[3]。しかし、それ以外の場合、サーバのデータを送信または変更するウェブフォームのほとんどは、その目的にPOSTを使用し続けている^[要出典]。

だからといって、すべてのウェブフォームが開始タグでmethod="post"を指定すべきだというわけではない。多くのフォームは、メインのデータベースを変更する意図はなく、サーバからの情報の取得をより正確に指定するために使用される。例えば検索フォームは、method="get"を指定するのに最適である^[4]。

データの取得であっても、HTTP GETがあまり適していない場合がある。その一例は、URLに大量のデータを指定する必要がある場合である。ブラウザやウェブサーバには、切り捨てやエラーなしで処理できるURLの長さに制限がある場合がある。URLやクエリストリング内の予約文字をパーセントエンコーディングすると、その長さが大幅に増加する可能性がある。Apache HTTP ServerはURLで最大4,000文字を処理できるが^[5]、2022年にサポートが終了したMicrosoft Internet Explorerは、すべてのURLで2,083文字、最大パス長で2,048文字に制限されている^[6]。同様に、リクエストを完了するためにユーザー名やパスワードなどの機密情報を他のデータと一緒に送信する必要がある場合は、HTTP GETを使用すべきではない。たとえHTTPSを使用して転送中のデータの傍受を防いだとしても、ブラウザの履歴やウェブサーバのログには完全なURLが平文で含まれる可能性が高く、どちらかのシステムがハッキングされると公開される危険性がある。このような場合は、HTTP POSTを使用する必要がある^[7]。

ウェブブラウザがウェブフォーム要素からPOSTリクエストを送信する場合、デフォルトのインターネットメディアタイプは「application/x-www-form-urlencoded」である^[8]。これは、重複する可能性のあるキーを持つキーと値のペアをエンコードするためのフォーマットである。各キーと値のペアは「&」文字で区切られ、各キーはその値から「=」文字で区切られる。キーと値はどちらも、スペースを「+」文字に置き換え、その他のすべての非英数字にパーセントエンコーディングを使用することでエスケープされる^[9]。

例えば、以下のキーと値のペアは

Name: Liam Wylie
Age: 24
Formula: a+b == 21

次のようにエンコードされる。

Name=Liam+Wylie&Age=24&Formula=a%2Bb+%3D%3D+21

HTML 4.0以降では、フォームはRFC 2388で定義されているmultipart/form-dataでデータを送信することもできる（HTML 2.0への拡張として定義され、HTML 3.2で言及されている初期の実験的バージョンについてはRFC 1867も参照のこと）^[要出典]。

フォームが属するのと同じページへのPOSTという特殊なケースは、ポストバックと呼ばれる^[要出典]。

RFC 7231によると、POSTメソッドは冪等ではない。つまり、同一のリクエストを複数回送信しても、1回だけ送信したのと同じ効果が得られない場合があるということである。したがって、POSTは、ブログ記事へのコメントの送信やオンライン投票での投票など、実行されるたびに状態を変更するリクエストに適している。GETは副作用のないnullipotent（無副作用）であると定義されており、冪等な操作は「2回目以降のリクエストで副作用がない」とされている^[10][11]。このような理由から、検索エンジンのインデクサーなどのウェブクローラは、自動化されたリクエストがそうしたアクションを実行するのを防ぐために、通常はGETおよびHEADメソッドのみを使用する。

しかし、冪等なリクエストであってもPOSTが使用される理由があり、特にリクエストが非常に長い場合が該当する。URLの制限により、特にパーセントエンコーディングが原因で、GETメソッドが生成するクエリストリングが非常に長くなる可能性があるためである^[10]。

• POSTの分かりやすい定義
• HTTP仕様におけるPOST動詞
• “Deploying Storage in Google Cloud Platform”. Google Cloud Certified Associate Cloud Engineer Study Guide. Wiley. (2019). pp. 275-308. doi:10.1002/9781119564409.ch12. ISBN 9781119564409