私が収集できるものから、3つのカテゴリがあります。

1. 決して使用GETしないでくださいPOST
2. 決して使用POSTしないでくださいGET
3. どちらを使用してもかまいません。

私はこれらの3つのケースを想定して正しいですか？もしそうなら、それぞれのケースからいくつかの例は何ですか？

POST作成（皮肉を承知しています）、編集、削除などの破壊的なアクションに使用しPOSTます。これは、ブラウザーのアドレスバーでアクションを押すことができないためです。GET人がアクションを呼び出せるようにすることが安全なときに使用します。したがって、次のようなURL：

http://myblog.org/admin/posts/delete/357

単にアイテムを削除するのではなく、確認ページに移動するはずです。この方法で事故を回避する方がはるかに簡単です。

POSTまたGET、URLに情報を貼り付けないため、より安全です。そして、パスワードやその他の機密情報を収集するHTMLフォームのGETとして使用methodすることは、最良の考えではありません。

最後に、1つPOST以上の情報を送信できGETます。「POST」には送信データのサイズ制限はありませんが、「GET」は2048文字に制限されています。

簡単に

• 使用GETのためのsafe andidempotent要求
• 使用POSTのためのneither safe nor idempotent要求

詳しく はそれぞれに適切な場所があります。RESTfulの原則に従わない場合でも、RESTとリソース指向のアプローチがどのように機能するかを学ぶことで多くを得ることができます。

RESTfulアプリケーションはuse GETs、両方の操作に対応しますsafe and idempotent。

safe操作がない操作ですnot change the data要求されました。

idempotent演算結果がしますものであるbe the sameあなたがそれを要求した回数に関係なく。

それはのために使用されているにつれて、という理由に立って安全な操作、彼らはまた、自動的にあるべき等。通常、GETは、リソース（たとえば、スタックオーバーフローに関する質問とそれに関連する回答）またはリソースのコレクションを取得するために使用されます。

RESTfulアプリはPUTs、次の操作に使用しますnot safe but idempotent。

GETとPOSTに関する質問だったのはわかっていますが、すぐにPOSTに戻ります。

通常、PUTはリソースの編集（たとえば、スタックオーバーフローでの質問または回答の編集）に使用されます。

A POSTは、すべての操作に使用されますneither safe or idempotent。

通常、POSTは新しいリソースを作成するために使用され、たとえばNEW SO質問を作成します（一部の設計ではPUTもこれに使用されます）。

POSTを2回実行すると、2つの新しい質問が作成されます。

DELETE操作もありますが、私はそれをそこに残すことができると思います:)

討論

実際には、最新のWebブラウザーは通常、GETとPOSTのみを確実にサポートします（これらの操作はすべてJavaScript呼び出しで実行できますが、フォームへのデータの入力と送信を押すという点では、通常2つのオプションがあります）。RESTfulアプリケーションでは、POSTがオーバーライドされて、PUTおよびDELETE呼び出しも提供されることがよくあります。

ただし、RESTfulの原則に従っていない場合でも、GETを使用して情報を取得/表示し、POSTを使用して情報を作成/編集することを考えると便利です。

データを変更する操作にはGETを使用しないでください。検索エンジンが悪意のある操作へのリンクをクロールする場合、またはクライアントがブックマークを付ける場合、大きな問題を引き起こす可能性があります。

リクエストが繰り返されることを気にしない場合は、GETを使用してください（つまり、状態は変更されません）。

操作がシステムの状態を変更する場合は、POSTを使用します。

短縮版

GET：通常は、送信された検索リクエスト、またはユーザーが正確なページを再度プルアップできるようにするリクエストに使用されます。

GETの利点：

• URLは安全にブックマークできます。
• ページは安全に再読み込みできます。

GETの短所：

• 変数は、名前と値のペアとしてurlを介して渡されます。（セキュリティリスク）
• 渡すことができる変数の数に制限があります。（ブラウザに基づきます。たとえば、Internet Explorerは2,048文字に制限されています。）

POST：データベースを変更するためにデータが使用される可能性のあるより高いセキュリティ要求、または誰かにブックマークを付けたくないページに使用されます。

POSTの利点：

• 名前と値のペアはURLに表示されません。（セキュリティ+ = 1）
• 無制限の数の名前と値のペアをPOST経由で渡すことができます。参照。

POSTの短所：

• POSTデータを使用したページはブックマークできません。（必要に応じて）

長いバージョン

ハイパーテキスト転送プロトコルから直接-HTTP / 1.1：

9.3 GET

GETメソッドは、Request-URIで識別される情報（エンティティーの形式）を取得します。Request-URIがデータ生成プロセスを参照している場合、そのテキストがたまたまプロセスの出力である場合を除き、プロセスのソーステキストではなく、応答のエンティティとして返されるのは生成されたデータです。

リクエストメッセージにIf-Modified-Since、If-Unmodified-Since、If-Match、If-None-Match、またはIf-Rangeヘッダーフィールドが含まれている場合、GETメソッドのセマンティクスは「条件付きGET」に変わります。条件付きGETメソッドは、エンティティが条件付きヘッダーフィールドで記述された状況でのみ転送されることを要求します。条件付きGETメソッドは、複数のリクエストを要求したり、クライアントがすでに保持しているデータを転送したりせずに、キャッシュされたエンティティを更新できるようにすることで、不要なネットワーク使用量を減らすことを目的としています。

リクエストメッセージにRangeヘッダーフィールドが含まれている場合、GETメソッドのセマンティクスは「部分的なGET」に変わります。部分的なGETは、セクション14.35で説明されているように、エンティティの一部のみが転送されることを要求します。部分的なGETメソッドは、クライアントが既に保持しているデータを転送せずに部分的に取得されたエンティティを完了できるようにすることで、不要なネットワーク使用量を減らすことを目的としています。

GET要求への応答は、セクション13で説明されているHTTPキャッシングの要件を満たしている場合にのみキャッシュ可能です。

フォームに使用する場合のセキュリティに関する考慮事項については、セクション15.1.3を参照してください。

9.5投稿

POSTメソッドを使用して、オリジンサーバーがリクエストに含まれるエンティティを、Request-LineのRequest-URIで識別されるリソースの新しい下位として受け入れるように要求します。POSTは、以下の機能をカバーする統一された方法を可能にするように設計されています。

• 既存のリソースの注釈。

• 掲示板、ニュースグループ、メーリングリスト、または同様の記事グループにメッセージを投稿する。

• フォームの送信結果などのデータブロックをデータ処理プロセスに提供する。

• 追加操作によるデータベースの拡張。

POSTメソッドによって実行される実際の機能はサーバーによって決定され、通常はRequest-URIに依存します。投稿されたエンティティは、ファイルがそれを含むディレクトリに従属している、ニュース記事が投稿先のニュースグループに従属している、またはレコードがデータベースに従属しているのと同じように、そのURIに従属しています。

POSTメソッドによって実行されるアクションは、URIで識別できるリソースにならない場合があります。この場合、応答に結果を説明するエンティティが含まれているかどうかに応じて、200（OK）または204（コンテンツなし）が適切な応答ステータスです。

最初に重要なことは、GETとPOSTの意味です。

• GETを使用して... サーバーからいくつかの情報を取得する必要があります。
• 一方、POSTを使用してサーバーに情報を送信する必要があります。

その後、注意できることがいくつかあります：

• GETを使用すると、ユーザーはブラウザの「戻る」ボタンを使用でき、ページをブックマークできます
• GETとして渡すことができるパラメーターのサイズには制限があります（私が誤っていない場合、一部のバージョンのInternet Explorerでは2KB）。POSTの制限ははるかに大きく、通常はサーバーの構成によって異なります。

とにかく、GETなしでは「生きる」ことができないと思います。クエリ文字列のパラメーターで毎日使用しているURLの数を考えてください。GETなしでは、すべてのURLは機能しません;-)

多くのWebブラウザーにおける長さの制約の違いとは別に、意味上の違いもあります。GETは、サーバーの状態を変更しない読み取り専用の操作であるため、「安全」であると見なされます。POSTは通常状態を変更し、再送信時に警告を表示します。検索エンジンのWebクローラーはGETを実行できますが、POSTを実行してはなりません。

状態を変更せずにデータを読み取りたい場合はGETを使用し、サーバーの状態を更新したい場合はPOSTを使用します。

私の一般的な経験則は、状態を変更しないサーバーにリクエストを送信するときにGetを使用することです。投稿は、状態を変更するサーバーへのリクエストのために予約されています。

実用的な違いの1つは、ブラウザーとWebサーバーでは、URLに含めることができる文字数に制限があることです。アプリケーションごとに異なりますがtextarea、フォームにsが含まれている場合は、ヒットする可能性があります。

GETのもう1つの問題-検索エンジンやその他の自動システムによってインデックスが作成されます。Googleには、表示しているページのリンクをプリフェッチする製品があったため、これらのリンクをクリックすると、ロードが速くなります。それは、人々がサイト全体を失ったようなリンクのあるサイトに大きな混乱を引き起こしましたdelete.php?id=1。

URLにページの状態を反映させる場合は、GETを使用します。これは、ここに示すような動的に生成されたページを表示するのに役立ちます。POSTは、「Post Your Answer」ボタンをクリックするときなど、フォームでデータを送信するために使用する必要があります。また、パスの後にパラメーター文字列を生成しないため、よりクリーンなURLが生成されます。

GETは純粋なURLであるため、Webブラウザーでキャッシュすることができ、一貫して生成された画像などに使用することができます。（有効期限を設定）

グラバターページの1つの例：http ://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802 ? d=monsterid

GETは、パフォーマンスがわずかに向上する可能性があります。一部のWebサーバーは、ハンドラーを呼び出す前に一時ファイルにPOSTコンテンツを書き込みます。

考慮すべきもう1つのことは、サイズ制限です。GETは、URLのサイズ（標準では1024バイト）によって制限されますが、ブラウザーはそれより多くをサポートする場合があります。

それより多くのデータを転送する場合は、POSTを使用してブラウザの互換性を向上させる必要があります。

別の投稿者が書いたように、その制限よりも小さいことが問題であり、URLのすべてが、履歴など、ブラウザーのUIの他の部分に残る可能性があります。

自分でできないことは何もありません。ポイントは、HTTP GETでサーバーの状態を変更することを想定していないことです。HTTPプロキシは、HTTP GETが状態を変更しないため、ユーザーがHTTP GETを1回呼び出すか1000回呼び出すかは違いがないと想定しています。この情報を使用して、最初のHTTP GETのキャッシュバージョンを返すことが安全であると想定します。HTTP仕様に違反すると、実際にHTTPクライアントとプロキシが破壊される危険があります。それをしないでください:)

これは、RESTの概念と、Webがどのように使用されることを意図していたかを調べます。ソフトウェアエンジニアリングのラジオには優れたポッドキャストがあり、Get and Postの使用について詳しく説明しています。

Getは、更新アクションが不要なサーバーからデータをプルするために使用されます。つまり、同じGETリクエストを何度も使用でき、同じ情報が返されるはずです。URLは、クエリ文字列に取得情報が含まれています。これは、他のシステムや、何かを見つける場所のアドレスなどの人々に簡単に送信できるようにするためです。

Postは、サーバーに情報をプッシュしたり、アクションを実行するようにサーバーに通知したりするために（少なくともWebが基にしているRESTアーキテクチャによって）使用されることになっています。例：このデータを更新する、このレコードを作成する。

1.3 HTTP GETまたはを選択するためのクイックチェックリストPOST

次の場合はGETを使用します。

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

次の場合はPOSTを使用します。

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

ソース。

getを使用しても問題は発生しませんが、クエリ文字列を維持することが理にかなっている単純なものに使用します。

GETのようなdelete.php?id=5ページの削除のように、それを使用して状態を更新することは非常に危険です。Googleのウェブアクセラレータがページ上のURLのプリフェッチを開始したとき、人々はそれを発見しました-それはすべての「削除」リンクにヒットし、人々のデータを一掃しました。検索エンジンスパイダーでも同じことが起こります。

POSTは大きなデータを移動できますが、GETはできません。

ただし、一般的には、GETの短所ではなく、ウェブサイト/ウェブアプリの動作を適切にしたい場合の規約です。

見てhttp://www.w3.org/2001/tag/doc/whenToUseGet.html

RFC 2616から：

9.3 GET
GETメソッドは、Request-URIで識別される情報（エンティティーの形式）を取得します。Request-URIがデータ生成プロセスを参照している場合、そのテキストがたまたまプロセスの出力である場合を除き、プロセスのソーステキストではなく、応答のエンティティとして返されるのは生成されたデータです。

9.5 POST
POSTメソッドは、要求に含まれるエンティティを、オリジンサーバーがRequest-LineのRequest-URIで識別されるリソースの新しい下位として受け入れることを要求するために使用されます。POSTは、以下の機能をカバーする統一された方法を可能にするように設計されています。

• 既存のリソースの注釈。
• 掲示板、ニュースグループ、メーリングリスト、または同様の記事グループにメッセージを投稿する。
• フォームの送信結果などのデータブロックをデータ処理プロセスに提供する。
• 追加操作によるデータベースの拡張。

POSTメソッドによって実行される実際の機能はサーバーによって決定され、通常はRequest-URIに依存します。投稿されたエンティティは、ファイルがそれを含むディレクトリに従属している、ニュース記事が投稿先のニュースグループに従属している、またはレコードがデータベースに従属しているのと同じように、そのURIに従属しています。

POSTメソッドによって実行されるアクションは、URIで識別できるリソースにならない場合があります。この場合、応答に結果を説明するエンティティが含まれているかどうかに応じて、200（OK）または204（コンテンツなし）が適切な応答ステータスです。

私は、人々にQueryStringを見せたくない場合、またはQueryStringが大きくなる場合にPOSTを使用します。また、ファイルのアップロードにはPOSTが必要です。

GETを使用しても問題はありませんが、QueryStringを維持することが理にかなっている単純なものに使用します。

GETを使用すると、POSTが機能しない特定のページへのリンクも可能になります。

元々の意図は、GETがデータの取得に使用され、POSTは何であってもよいということでした。私が使用する経験則では、サーバーに何かを送り返す場合はPOSTを使用します。データを取得するためにURLを呼び出すだけの場合は、GETを使用します。

ウィキペディアでHTTPに関する記事を読んでください。それはプロトコルが何であるか、そしてそれが何をするかを説明します：

取得する

指定されたリソースの表現を要求します。GETは、Webアプリケーションでアクションを実行するために使用するなど、副作用を引き起こす操作には使用しないでください。この理由の1つは、GETがロボットまたはクローラーによって任意に使用される可能性があるためです。これにより、要求が引き起こす副作用を考慮する必要がなくなります。

そして

POST 処理するデータを（たとえば、HTMLフォームから）識別されたリソースに送信します。データはリクエストの本文に含まれています。これにより、新しいリソースの作成、既存のリソースの更新、またはその両方が発生する可能性があります。

W3Cには、URI、アドレス可能度、および何をいつ使用するかを説明するHTTP GETおよびPOSTの使用という名前のドキュメントがあります。引用

1.3 HTTP GETまたはPOSTを選択するためのクイックチェックリスト

• 次の場合はGETを使用します。
  • 相互作用は、質問のようなものです（つまり、クエリ、読み取り操作、ルックアップなどの安全な操作です）。

そして

• 次の場合はPOSTを使用します。
  • 相互作用は注文のようなものです
  • 対話は、ユーザーが認識する方法でリソースの状態を変更します（たとえば、サービスへのサブスクリプション）。または、o対話の結果に対する責任はユーザーにあります。

ただし、HTTP GETまたはPOSTの使用を最終的に決定する前に、機密データの考慮事項と実際の考慮事項も検討してください。

実際の例は、HTMLフォームを送信するときです。フォームアクションには、postまたはgetを指定します。PHPは$ _GETと$ _POSTを適宜入力します。

PHPでは、POSTデータ制限は通常によって設定されますphp.ini。GET私が信じるサーバー/ブラウザの設定によって制限されます-通常はおよそ255バイトです。

w3schools.comから：

HTTPとは何ですか？

ハイパーテキスト転送プロトコル（HTTP）は、クライアントとサーバー間の通信を可能にするように設計されています。

HTTPは、クライアントとサーバー間の要求/応答プロトコルとして機能します。

Webブラウザがクライアントである場合があり、Webサイトをホストするコンピュータ上のアプリケーションがサーバーである場合があります。

例：クライアント（ブラウザ）がHTTPリクエストをサーバーに送信します。次に、サーバーはクライアントに応答を返します。応答には、リクエストに関するステータス情報が含まれ、リクエストされたコンテンツが含まれる場合もあります。

2つのHTTP要求メソッド：GETおよびPOST

クライアントとサーバー間の要求/応答に一般的に使用される2つの方法は、GETとPOSTです。

GET –指定したリソースからのデータを要求しますPOST –処理するデータを指定したリソースに送信します

ここでは、主な違いを区別します。

POST GET PUT DELETEのシンプルなバージョン

• GETを使用-任意のIDまたは名前に基づくデータのリストなどのリソースを取得する場合
• サーバーにデータを送信する場合は、POSTを使用します。更新の場合、内部的にPOSTではなくPUTを使用する必要があるため、POSTは重い操作であることに注意してください。POSTは新しいリソースを作成します
• PUTを使用する-あなたが

重要なことの1つは、送信したものはすべてGETURL経由で公開されることです。次に、Ceejayozが言うように、URLの文字数には制限があります。

もう1つの違いは、POSTでは通常2つのHTTP操作が必要なのに対し、GETでは1つしか必要ないことです。

編集：私は明確にする必要があります-一般的なプログラミングパターンについて。通常、まっすぐなHTML WebページでPOSTに応答することは、さまざまな理由で疑わしい設計です。その1つは、「このフォームを再送信する必要があります。再送信しますか？」戻るボタンを押すと

他の人が答えたように、getではURLサイズに制限があり、ファイルは投稿のみで送信できます。

私はできることを追加したいと思いますgetを使用してデータベースに何かを追加し、postを使用してアクションを実行ます。スクリプトは投稿または取得を受け取ると、作成者が望んでいることをすべて実行できます。理解の欠如は、本が選んだ言葉遣いやあなたがそれをどのように読んだかから来ていると思います。

スクリプト作成者は、投稿を使用してデータベースを変更し、getを使用して情報を取得する必要があります。

スクリプト言語は、リクエストにアクセスするための多くの手段を提供しました。たとえば、PHPではを使用し$_REQUESTて投稿または取得を取得できます。より具体的な$_GETorを優先してこれを回避する必要があります$_POST。

Webプログラミングでは、解釈の余地が多くあります。何をすべきか、何ができるかはありますが、どちらが優れているかは議論の余地があります。幸い、この場合、あいまいさはありません。あなたはすべきデータを変更するためにポストを使用し、あなたがすべき情報を取得するために、getを使用します。

Gorgapor、mod_rewriteまだ頻繁に利用しGETます。使いやすいURLをGETクエリ文字列を含むURLに変換するだけです。

HTTP Postデータには、データ量に特定の制限はありません。これは、ブラウザによってGETの制限が異なるためです。RFC 2068は次のように述べています。

サーバーは、255バイトを超えるURIの長さに依存することに注意する必要があります。これは、一部の古いクライアントまたはプロキシの実装がこれらの長さを適切にサポートしていない場合があるためです。

具体的には、使用目的に応じて適切なHTTPコンストラクトを使用する必要があります。HTTP GETには副作用がなく、HTTPプロキシなどで安全に更新および保存できます。

HTTP POSTは、URLリソースに対してデータを送信するときに使用されます。

HTTP GETを使用する一般的な例は、検索（例：Search？Query = my + query）です。HTTPPOSTを使用する一般的な例は、オンラインフォームにフィードバックを送信することです。