HTTP リクエスト メソッドの GET と POST の主な違いは何ですか?

目的

• GET はリソースの表現を要求します。仕様により、これは読み取り専用です。クライアントはサーバーの状態の変更を予期しません。 RFC 9110 では、GET リクエストでの本文の送信には未定義のセマンティクスがあるため、GET で本文を送信すべきではないと述べています。
• POST は、ターゲット リソースに対して、そのリソース独自のセマンティクスに従ってリクエスト本文に含まれるデータを処理するように要求します (レコードの作成、フォームの送信、ファイルのアップロードなど)。

データの保存先

• GET は、URL クエリ文字列 (? の後、key=value&... としてフォーマット) 内のパラメータを運びます。これらはアドレス バーに表示され、ブラウザ履歴とサーバー ログに記録され、実際の URL 長制限によって制限されます。
• POST はリクエスト本文にデータを運びます。タイプは Content-Type ヘッダーによって指定されます。 HTML フォームは通常、application/x-www-form-urlencoded (デフォルト) または multipart/form-data (ファイル用) を使用します。固定のプロトコル レベルのサイズ制限はありませんが、サーバーとプロキシは独自の最大値を設定します (例: Nginx client_max_body_size)。

RFC 9110 に基づくプロパティ

• 安全: GET は安全です (読み取り専用)。 POSTはそうではありません。
• 冪等: リクエストを N 回実行すると、サーバーの状態に 1 回実行した場合と同じ影響がある場合、リクエストは冪等です。 GET はべき等です。 POST はそうではありません。これを繰り返すと、2 つの同一の注文など、重複が作成される可能性があります。冪等は安全と同じではなく (PUT と DELETE は冪等ですが安全ではありません)、応答本文が同一であることについては何も述べていません。
• キャッシュ可能: GET 応答はデフォルトでキャッシュ可能です。 POST 応答は、明示的な鮮度情報と一致する Content-Location ヘッダーが含まれている場合にのみキャッシュ可能ですが、実際にはこれはまれです。

実際的な影響

• 取得とナビゲーションには GET を使用します。結果は安全に繰り返し、ブックマークし、プリフェッチすることができ、GET ページを更新しても無害です。
• 状態を変更するアクションや機密性の高いペイロードまたは大きなペイロードの送信には POST を使用します。 POST ページを更新するか、POST ページに戻ると、ブラウザの「フォームの再送信の確認」警告が表示されます。
• GET 経由でパスワードを送信しないでください。パスワードは URL、ログ、履歴に記録されます。これは暗号化ではなく衛生管理です。HTTPS は送信中に URL と本文の両方を暗号化しますが、URL はログに記録されます。

一般的なフォローアップ

• 安全なメソッドは GET、HEAD、OPTIONS です。べき等メソッドは GET、HEAD、PUT、DELETE です。 POSTはどちらでもありません。
• どちらの方法も HTML フォーム (method 属性) でサポートされています。
• RFC の意味での「安全」とは、状態が変化しないことを意味し、データ保護ではありません。
• アプリケーション レベルの POST 冪等性は、冪等性キーを使用して強制されることがよくあります。