突然のビデオインタビューで気が狂いました。頭の中でほこりっぽい知識を探してみましたが、何も見つからなかったので、このブログを読んでくださる皆さんのお役に立てればと思い、レビューして記録しました。
最初のものは最もよく知られているものであり、それはW3Schoolによって与えられた「答え」です。
取得する
クエリ文字列（名前と値のペア）は、GETリクエストのURLで送信されることに注意してください。
/test/demo_form.php?name1=value1&name2=value2
- GETリクエストはキャッシュできます
- GETリクエストはブラウザの履歴に保持されます
- GETリクエストはブックマークできます
- 機密データを処理するときにGETリクエストを使用しないでください
- GETリクエストには長さ制限があります
- GETリクエストは、データをリクエストするためにのみ使用されます（変更なし）
役職
POSTは、リソースを作成/更新するためにサーバーにデータを送信するために使用されます。
POSTを介してサーバーに送信されたデータは、HTTPリクエストのリクエスト本文に保存されます。
POST /test/demo_form.php HTTP / 1.1
ホスト：w3schools.com
name1 = value1＆name2 = value2
- POSTリクエストがキャッシュされることはありません
- POSTリクエストはブラウザの履歴に残りません
- POSTリクエストでブックマークを追加できません
- POSTリクエストにはデータ長に制限はありません
W3Schoolからのこの標準的な回答は、2つの違いについて詳しく説明していますが、それだけでは十分ではありません。
まず、「idempotent」という用語を学ぶ必要があります。HTTPメソッドがidempotentであると言えば、同じリクエストが1回実行され、連続して複数回実行されることを意味します。同一効力のある方法には副作用があってはなりません。正しく実装されている場合、GET、HEAD、PUT、DELETE、およびその他のメソッドはすべて同一ですが、POSTメソッドはそうではありません。すべての安全な方法も同じです。
Idempotenceは、バックエンドサーバーの実際のステータスにのみ関連しており、各要求に対して受信されるステータスコードは必ずしも同じではありません。たとえば、DELETEメソッドへの最初の呼び出しは200を返す場合がありますが、後続の要求は404を返す場合があります。DELETEの意味は、開発者がDELETEメソッドを使用して最後のエントリを削除する機能を持つRESTfulAPIを実装しないことです。
GET /pageX HTTP/1.1同一の効力があります。連続して複数回呼び出された場合、クライアントが受け取る結果は同じです。
GET / pageX HTTP / 1.1
GET / pageX HTTP / 1.1
GET / pageX HTTP / 1.1
GET / pageX HTTP / 1.1
POST /add_row HTTP/1.1同一ではありません。複数回呼び出された場合、レコードの複数の行が追加されます。
POST / add_row HTTP / 1.1
POST / add_row HTTP / 1.1-> 2行目を追加
POST / add_row HTTP / 1.1-> 3行目を追加
DELETE /idX/delete HTTP/1.1異なるリクエスト間で受信したステータスコードが異なっていても、それは同じです。
DELETE / idX / delete HTTP / 1.1-> idXが存在する場合は200を返します
DELETE / idX / delete HTTP /1.1->削除されたばかりの404を返します
DELETE / idX / delete HTTP / 1.1-> 404を返します
したがって、POSTとGETのどちらがより安全であるかは問題ではなく、用途は異なります。
GETは、コンテンツを変更せずに表示したり、リモートデータを取得して指定されたリソースを要求したりするために使用されます。
POSTは、一部のコンテンツを変更するため、つまり、識別されたリソースに処理データを送信するために使用されます
たとえば、検索ページではGETを使用し、パスワード変更フォームではPOSTを使用する必要があります。
HTTP / 1.1仕様（RFC 2616）のセクション15のセキュリティに関する考慮事項では、データの取得にGETのみを使用する必要がある理由について説明しています。
HTTPプロトコルを使用するサービスの作成者は、機密データの送信にGETベースのフォームを使用しないでください。これにより、このデータがRequest-URIにエンコードされるためです。多くの既存のサーバー、プロキシ、およびユーザーエージェントは、サードパーティに表示される可能性のある場所にリクエストURIを記録します。サーバーは代わりにPOSTベースのフォーム送信を使用できます
一般的な意味は次のとおりです。HTTPプロトコルを使用する作成者は、GETを使用して機密データを送信しないでください。これにより、データが要求URIにエンコードされます。多くの既存のサーバー、プロキシ、およびユーザーエージェントは、サードパーティの一部の場所に表示されます。サーバーは、代わりにPOSTベースのフォーム送信を使用できます。
PHPでは、この2つの概念は少し混乱します。POSTリクエストは、クエリ文字列からリクエスト本文を介して入力を取得します。GETリクエストは、クエリ文字列からの入力のみを取得します。したがって、POSTリクエストはGETリクエストのスーパーセットであると言えます。POSTリクエストで$ _GETを使用できます。また、$ _ POSTと$ _GETで同じ名前のパラメーターでさえ、意味が異なり、意味がある場合もあります。
たとえば、記事を編集するためのフォームがあり、タイトルIDがクエリ文字列に含まれている可能性があり、$ _ GET ['id']を使用して取得できますが、タイトルIDを変更するとします。新しいIDがリクエスト本文に表示されます：$ _ POST ['id']。
最後に、非常に重要な点があります。GETメソッドをAJAXリクエストに適用する場合、一部のブラウザ、特にInternetExplorerはリクエストの結果をキャッシュします。したがって、同じGET要求をポーリングに使用すると、照会するデータがサーバー側で更新された場合でも、常に同じ結果が返されます。この問題を軽減する1つの方法は、タイムスタンプを追加して、要求された各URLを一意にすることです。
次のコードを使用して、次のことを実現できます。
var timestamp = new Date().getTime();
url = url + '?t=' + timestamp;卒業プロジェクトでこの問題に悩まされていたのですが、GETメソッドの本質が原因だとは思いませんでした。このレビューを通して、忘れられていた知識を学び、新しい知識を身につけました。
このブログ投稿はメモのようなもので、構造が少し乱雑で、より恣意的です。このブログ投稿を読むのに役立つことを願っています。このブログ投稿が気に入ったら、いいねまたはワンクリックのトリプルリンクを付けてください。ご支援いただきありがとうございます。 ！
リファレンスカタログ：
StackOverflow：POSTとGETの違いは何ですか？[複製]
StackOverflow：いつGETまたはPOSTメソッドを使用する必要がありますか？それらの違いは何ですか？
W3C：プロトコル-HTTP / 1.1 RFC 2616：15セキュリティに関する考慮事項
W3School：HTTPリクエストメソッド
php.net：$ _POST