GET

使い方

GET リクエストは、サーバーの状態を変更せずにデータを取得します。リクエストボディに含まれる内容には一般的に定義されたセマンティクスがなく、クエリ全体はターゲット URI とヘッダーによって表現されます。レスポンスはデフォルトでキャッシュ可能であり、これが GET を Web キャッシュの基盤にしています。

GET は、ナビゲーション、リンクのクリック、method 属性のないフォーム送信におけるブラウザのデフォルトです。

HTTP 仕様は GET リクエストでのボディを禁止していませんが、そのボディのセマンティクスは未定義です。ブラウザと Fetch API は GET リクエストのボディを取り除きます。多くのサーバーとプロキシはそれを無視するか拒否します。GET リクエストのボディに依存することは、相互運用性の観点から安全ではありません。

特性

GET は安全かつ冪等であるため、同じリクエストを複数回送信しても同じ結果が得られ、リソースは変更されません。ブラウザ、クローラー、プロキシはいずれもこの保証に依存しています。

条件付き GET

GET リクエストは、1つ以上のバリデーターヘッダー（If-Match、If-None-Match、If-Modified-Since、If-Unmodified-Since、If-Range）が存在すると条件付きになります。サーバーは条件を評価し、条件が満たされた場合にのみ完全な表現を返します。

部分 GET

Range ヘッダーを含めると、GET は部分リクエストになります。サーバーは要求されたバイト範囲のみを 206 ステータスとともに返します。416 ステータスは、その範囲が満たせないことを示します。範囲リクエストをサポートしないサーバーは、完全なボディとともに 200 を返します。

部分 GET は、中断されたダウンロードの再開や、大きなファイルをセグメント単位でストリーミングする際に役立ちます。

基本的な GET

最小限の GET リクエストはルートリソースを取得します。サーバーは完全な表現とともに 200 を返します。

リクエスト

GET / HTTP/1.1
Host: example.com

レスポンス

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<!doctype html>
<html>...

条件付き GET

このリクエストには If-Modified-Since が含まれているため、サーバーは指定された日付以降にリソースが変更された場合にのみボディを返します。変更されていないリソースの場合は、ボディなしの 304 になります。

リクエスト

GET / HTTP/1.1
Host: example.com
If-Modified-Since: Sat, 01 Jan 2022 12:00:00 GMT

レスポンス（未変更）

HTTP/1.1 304 Not Modified
ETag: "abc123"

部分 GET

Range ヘッダーは最初の 512 バイトのみを要求します。サーバーは 206 と、返却したセグメントを示す Content-Range ヘッダーで応答します。

リクエスト

GET /file.bin HTTP/1.1
Host: example.com
Range: bytes=0-511

レスポンス

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-511/8192
Content-Length: 512

CORS

GET は CORS セーフリストメソッドです。クロスオリジンの GET リクエストはプリフライトリクエストを発生させないため、GET はブラウザにおけるクロスオリジンのリソース取得のデフォルトメソッドとなっています。

GET と POST の比較

GET はデータを取得します。POST は処理のためにデータを送信します。GET のパラメーターは URL のクエリ文字列を通じて運ばれ、POST のパラメーターはリクエストボディに入ります。

GET のレスポンスはキャッシュ可能でブックマーク可能です。POST のレスポンスは明示的な鮮度情報がある場合にのみキャッシュ可能です。URL には実用上の長さ制限があり、GET が運べるデータ量を制限します。POST には実用上のボディサイズ制限がありません。

GET は安全かつ冪等です。POST はそのどちらでもありません。GET を繰り返すと同じ結果が返ります。POST を繰り返すと、重複したリソースが作成されるか、処理が2回発生します。

GET と POST のパフォーマンスの差は無視できる程度です。選択は操作内容によって決まります。取得には GET を、送信には POST を使います。

セキュリティ

GET のパラメーターは URL、ブラウザの履歴、サーバーログ、Referer ヘッダーに表示されます。パスワード、トークン、個人を特定できる情報などの機微なデータは、決してクエリ文字列に含めてはいけません。

GET リクエストは、自動的に GET リクエストを発生させるタグやタグを通じた CSRF 攻撃により多くさらされています。POST も適切なトークンがなければ CSRF に対して脆弱です。

GET も POST も、それ自体では暗号化を提供しません。転送中のデータを保護するには HTTPS が必要です。

SEO への影響

検索エンジンは GET でクロールします。Googlebot をはじめとするクローラーは GET でページを取得してインデックスするため、リソースは素の GET に応答する場合にのみ発見可能になります。キャッシュ可能で冪等な GET レスポンスは最も効率的にクロールされます。クローラーは ETag や Last-Modified といったバリデーターを再利用して、変更されていないページの再取得をスキップするためです。