POST をいつ使用し、GET をいつ使用しますか?

Question

私が収集した情報によると、次の 3 つのカテゴリがあります。

1. 絶対に使用しないでください GET そして使用します POST
2. 絶対に使用しないでください POST そして使用します GET
3. どちらを使用しても問題ありません。

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

Answer 1

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

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

アイテムを単に削除するのではなく、確認ページが表示されます。こうすることで事故を避けるのがはるかに簡単になります。

POST よりも安全です GET, URLに情報を埋め込んでいないからです。そして、それを使用して GET として method パスワードやその他の機密情報を収集する HTML フォームの場合は、最善のアイデアではありません。

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

Answer 2

簡単に言うと

• 使用 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 はリソースの編集 (スタック オーバーフローに関する質問や回答の編集など) に使用されます。

あ 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 を決して使用しないでください。検索エンジンが邪悪なオペレーションへのリンクやクライアントのブックマークをクロールすると、大きな問題が発生する可能性があります。

Answer 3

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

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

Answer 4

短縮版

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

GET の利点:

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

GET のデメリット:

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

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

POST の利点:

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

POST の欠点:

• POSTデータを使用したページはブックマークできません。(ご希望であれば。)

ロングバージョン

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

9.3 取得

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メソッドは、リクエストラインのリクエスト-URIによって識別されたリソースの新しい部下として、リクエストに囲まれたエンティティをOrigin Serverが受け入れることを要求するために使用されます。Postは、均一な方法で次の機能をカバーできるように設計されています。

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

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

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

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

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

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

Answer 5

まず重要なことは、 意味 GET と POST の比較:

• GET は次の目的で使用する必要があります...得る...いくつかの情報 から サーバー、
• 一方、POST は何らかの情報を送信するために使用する必要があります に サーバー。

その後、注目すべき点がいくつかあります。

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

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

Answer 6

多くの Web ブラウザーでは長さの制約の違いとは別に、セマンティクスの違いもあります。GET はサーバーの状態を変更しない読み取り専用操作であるため、「安全」であると考えられています。通常、POST は状態を変更し、再送信時に警告を出します。検索エンジンの Web クローラーは GET を行う場合がありますが、POST を行うべきではありません。

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

Answer 7

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

Answer 8

実際の違いの 1 つは、ブラウザと Web サーバーには URL に存在できる文字数に制限があることです。アプリによって異なりますが、 textareaフォームにあります。

GET にはもう 1 つの問題があります。GET は検索エンジンやその他の自動システムによってインデックスが作成されます。Google にはかつて、閲覧しているページ上のリンクを事前に取得する製品があり、そのリンクをクリックするとリンクがより速く読み込まれるようになっていました。それが引き起こした 選考科目 次のようなリンクがあったサイトに大混乱が発生 delete.php?id=1 - 人々はサイト全体を失いました。

Answer 9

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

Answer 10

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

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

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

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

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

別の投稿者が書いているように、その制限を下回る場合でも問題があり、URL 内のすべてがブラウザの UI の他の部分 (履歴など) に表示される可能性があります。

Answer 11

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

Answer 12

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

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

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

Answer 13

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.

ソース.

Answer 14

get を使用しても問題はありませんが、クエリ文字列に内容を保持することが合理的である単純な目的で使用します。

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

Answer 15

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

ただし、一般的に、これは GET の欠点に関するものではなく、Web サイトや Web アプリケーションを適切に動作させたい場合の慣例です。

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

Answer 16

から RFC 2616:

9.3 得る
GETメソッドは、（エンティティの形式で）情報をリクエストURIによって識別されるものを取得することを意味します。リクエスト-URIがデータ生産プロセスを指す場合、それはプロセスのソーステキストではなく、プロセスのソーステキストではなく、応答のエンティティとして返される生成されたデータです。

9.5 役職
POSTメソッドは、リクエストラインのリクエスト-URIによって識別されたリソースの新しい部下として、リクエストに囲まれたエンティティをOrigin Serverが受け入れることを要求するために使用されます。Postは、均一な方法で次の機能をカバーできるように設計されています。

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

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

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

Answer 17

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

ただし、GET を使用しても問題はありません。私は、QueryString に内容を保持することが合理的である単純な目的で使用します。

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

Answer 18

POST GET PUT DELETEの簡易版

• GET を使用します - ID または名前に基づいてデータのリストなどのリソースを取得する場合
• POST を使用します - データをサーバーに送信する場合。ポストは重量操作であることに留意してください。アップデートのためには、内部的に投稿する代わりにPutを使用する必要があるため、新しいリソースが作成されます。
• PUT を使用します - 次の場合

Answer 19

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

Answer 20

読む ウィキペディアの HTTP に関する記事. 。プロトコルとは何か、またその機能について説明します。

得る

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

そして

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

W3C には次の名前の文書があります。 URI、アドレス指定可能性、HTTP GET および POST の使用 いつ何を使用するかを説明します。引用

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

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

そして

• 次の場合に POST を使用します。
  • このやりとりは命令に近い、または
  • 相互作用は、ユーザーが知覚する方法でリソースの状態を変更します（たとえば、サービスのサブスクリプション）、またはoユーザーは相互作用の結果に対して責任を負います。

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

実際の例としては、HTML フォームを送信するときが挙げられます。どちらかを指定します 役職 または 得る フォームアクションの場合。PHP はそれに応じて $_GET と $_POST を設定します。

Answer 21

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

Answer 22

から w3schools.com:

HTTPとは何ですか?

HyperText Transfer Protocol（HTTP）は、クライアントとサーバー間の通信を可能にするように設計されています。

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

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

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

2 つの HTTP リクエスト メソッド:取得と投稿

クライアントとサーバーの間のリクエスト応答に一般的に使用される2つの方法は次のとおりです。取得して投稿します。

取得 - 指定されたリソースの投稿からデータをリクエスト - 指定されたリソースに処理するデータを提出します

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

Answer 23

重要なことの 1 つは、提出する内容です。 GET URL経由で公開されます。次に、Ceejayoz 氏が言うように、URL には文字数の制限があります。

Answer 24

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

編集：一般的なプログラミング パターンについて、明確にしておかなければなりません。一般的に、まっすぐなHTML Webページを含む投稿に応答することは、さまざまな理由で疑わしいデザインです。バックボタンを押すと。

Answer 25

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

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

脚本家 すべき データベースを変更するには post を使用し、情報の取得には get のみを使用します。

スクリプト言語は、リクエストにアクセスするための多くの手段を提供しました。たとえば、PHP では次のような使用が可能です。 $_REQUEST post または get を取得します。より具体的なものを優先してこれを避けるべきです $_GET または $_POST.

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

Answer 26

ゴルガポール、 mod_rewrite 今でもよく利用します GET. 。よりわかりやすい URL を、 GET クエリ文字列。

Answer 27

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

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

具体的には、用途に応じて適切な HTTP 構造を作成する必要があります。HTTP GET には副作用がなく、HTTP プロキシなどによって安全に更新および保存できます。

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

HTTP GET を使用する典型的な例は、検索です。検索？query = my+query HTTP投稿を使用する典型的な例は、オンラインフォームにフィードバックを送信することです。