387

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

  1. 絶対に使わないGETで使うPOST
  2. 絶対に使わないPOSTで使うGET
  3. どちらを使用しても構いません。

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

4

27 に答える 27

422

POST作成 (皮肉なことは承知しています)、編集、削除などの破壊的なアクションに使用しPOSTます。ブラウザーのアドレス バーでアクションを実行できないためです。GET人がアクションを呼び出すことを許可しても安全な場合に使用します。したがって、次のような URL です。

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

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

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

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

于 2008-09-05T19:12:17.473 に答える
231

簡単に言えば

  • リクエスト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 は安全な操作に使用されるため、自動的に冪等でもあります。通常、GET は、リソース (たとえば、スタック オーバーフローに関する質問とそれに関連する回答) またはリソースのコレクションを取得するために使用されます。

RESTful アプリはPUTs、not safe but idempotent.

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

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

APOSTは、 であるすべての操作に使用されますneither safe or idempotent。

通常、POST は新しいリソースを作成するために使用されます。

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

DELETE 操作もありますが、そのままにしておくことができると思います :)

討論

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

ただし、RESTful の原則に従っていない場合でも、GET を使用して情報を取得/表示し、POST を使用して情報を作成/編集するという観点から考えると役立つ場合があります。

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

于 2008-09-05T19:18:03.573 に答える
84

リクエストが繰り返されても構わない場合は、GET を使用してください (つまり、状態が変化しません)。

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

于 2008-09-05T19:07:37.547 に答える
67

短縮版

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

GETの利点：

  • URLは安全にブックマークできます。
  • ページは安全にリロードできます。

GETのデメリット：

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

POSTの利点：

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

POSTのデメリット：

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

長いバージョン

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

9.3GET

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」に変わります。セクション14.35で説明されているように、部分的なGETは、エンティティの一部のみを転送することを要求します。部分的なGETメソッドは、クライアントが既に保持しているデータを転送せずに、部分的に取得されたエンティティを完了できるようにすることで、不要なネットワークの使用を減らすことを目的としています。

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

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

9.5 POST

POSTメソッドは、リクエストに含まれるエンティティを、リクエストラインのリクエストURIで識別されるリソースの新しい従属としてオリジンサーバーが受け入れるようにリクエストするために使用されます。POSTは、統一されたメソッドが次の機能をカバーできるように設計されています。

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

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

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

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

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

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

于 2009-06-03T09:42:42.620 に答える
30

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

  • GET は、サーバーから情報を取得するために使用する必要があります。
  • 一方、サーバーに情報を送信するには POST を使用する必要があります。


その後、次の点に注意してください。

  • GET を使用すると、ユーザーはブラウザの「戻る」ボタンを使用したり、ページをブックマークしたりできます
  • GET として渡すことができるパラメーターのサイズには制限があります(私が間違っていなければ、Internet Explorer の一部のバージョンでは 2KB です)。制限は POST でははるかに高く、一般的にサーバーの構成に依存します。


とにかく、私たちは GET なしで「生きていける」とは思いません: クエリ文字列のパラメータで毎日いくつの URL を使用しているか考えてみてください -- GET がなければ、それらすべてが機能しません ;-)

于 2010-02-15T17:49:10.523 に答える
8

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

于 2008-09-05T19:08:25.983 に答える
8

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

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

于 2010-02-15T17:48:30.883 に答える
7

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

于 2008-09-05T19:07:06.657 に答える
6

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

Gravatar ページからの一例: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

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

考慮すべきもう 1 つの点は、サイズの制限です。GET は URL のサイズによって制限されており、標準では 1024 バイトですが、ブラウザーはそれ以上をサポートしている場合があります。

それよりも多くのデータを転送するには、ブラウザの互換性を高めるために POST を使用する必要があります。

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

于 2008-09-06T08:46:15.893 に答える
4

これは、REST の概念と、Web がどのように使用されることを意図していたのかを説明しています。Get と Post の使用法について詳しく説明している優れたポッドキャストが Software Engineering radio で放送されています。

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

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

于 2008-09-05T19:23:31.550 に答える
4

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

于 2010-02-15T17:53:19.110 に答える
3

get を使用しても問題はありませんが、クエリ文字列に物事を保持することが理にかなっている単純なことに使用します。

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

于 2008-09-05T19:13:00.233 に答える
3

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 (コンテンツなし) のいずれかが適切な応答ステータスです。

于 2010-02-15T17:53:47.723 に答える
2

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

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

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

于 2008-09-05T19:09:22.377 に答える
1

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

于 2008-09-05T19:08:07.263 に答える
1

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

得る

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

と

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

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

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

  • 次の場合に GET を使用します。
    • 相互作用は質問に似ています (つまり、クエリ、読み取り操作、検索などの安全な操作です)。

と

  • 次の場合は POST を使用します。
    • インタラクションは注文に似ている、または
    • 対話は、ユーザーが認識する方法でリソースの状態を変更します (サービスへの加入など)。

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

実際の例は、HTML フォームを送信するときです。フォーム アクションには、postまたはgetのいずれかを指定します。PHP は、それに応じて $_GET と $_POST を入力します。

于 2010-02-15T17:54:49.887 に答える
1

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

于 2010-02-15T19:13:56.297 に答える
0

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

get を使用してデータベースに追加し、post を使用してアクションを実行できることを追加したいと思います。スクリプトが投稿または取得を受け取ると、作成者が実行したいことは何でも実行できます。理解の欠如は、本が選んだ言葉遣いや読み方に起因すると思います。

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

スクリプト言語は、リクエストにアクセスするための多くの手段を提供しました。たとえば、PHP では、$_REQUESTpost または get のいずれかを取得するために を使用できます。より具体的な$_GETorを優先して、これを避けるべき$_POSTです。

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

于 2010-02-15T18:22:59.107 に答える
-1

HTTP Post データには、データ量に指定された制限がありません。ブラウザごとに GET の制限が異なるためです。RFC 2068 には次のように記載されています。

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

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

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

HTTP GET を使用する典型的な例は、Search です。つまり、Search?Query=my+query HTTP POST を使用する典型的な例は、フィードバックをオンライン フォームに送信することです。

于 2010-02-15T17:52:03.323 に答える
-1

Gorgapor は、mod_rewrite今でもよく使用しGETます。GETより使いやすい URL をクエリ文字列を含む URL に変換できるようにするだけです。

于 2008-09-05T19:48:00.490 に答える