GET

GETメソッドは、対象リソースに対して現在選択されている表現の転送を要求します。 GET は情報検索の主要なメカニズムであり、ほとんどすべてのパフォーマンス最適化の焦点です。

リソースの識別子をリモートのファイルシステムのパス名と考え、表現をそのようなファイルの内容のコピーと考えたくなります。 実際、多くのリソースがそのように実装されています（関連するセキュリティ上の考慮点についてはセクション9.1を参照してください）。 しかし、実際にはそのような制限はありません。リソースのHTTPインターフェースは、コンテンツオブジェクトのツリーとして実装されたり、様々なデータベースレコードに対するプログラム的なビューとして実装されたり、他の情報システムへのゲートウェイとして実装されたりするのと同じようにあり得る。 URIマッピングの仕組みがファイルシステムと結びついている場合でも、オリジンサーバーはファイルを直接転送するのではなく、リクエストを入力としてファイルを実行し、出力を表現として送信するように構成されるかもしれません。

クライアントは、リクエストにRangeヘッダーフィールドを送ることで、GETのセマンティクスを「範囲リクエスト」に変更し、選択された表現の一部のみの転送を要求することができます(RFC7233)。

GETリクエストメッセージ内のペイロードは、定義されたセマンティクスを持たない。

GETリクエストでペイロードボディを送ることは、いくつかの既存の実装がリクエストを拒否する原因になるかもしれない。

GETリクエストに対する応答はキャッシュ可能である。キャッシュは、Cache-Controlヘッダーフィールド(RFC7234のセクション5.2)によって別段の指示がない限り、後続のGETリクエストとHEADリクエストを満たすためにそれを使用してもよい[MAY]。

HTTPプロトコルのGETメソッドは、デジタルな図書館員に例えることができます。それは、データ自体に変更を加えることなく、サーバにデータを提示するように丁寧に依頼します - これは純粋に受動的なリクエストです。

GETメソッドが特別なのはなぜか？

1. 一貫性：図書館員に同じ本を何度も求めると想像してみてください - 毎回同じ本をもらえます。GETリクエストも同じで、一貫して同じ結果を提供します。
2. 読むだけ、書き込みはしない：GETリクエストは観察者の性格を持っています。データを見るだけで、変更はしません。
3. URL内の情報：URLをアドレスや索引カードと考えてください。どの本や情報を探しているのかを示しています。しかし、注意が必要です：これらのカードにはプライベートなメモを含めるべきではありません、他の人に見られる可能性があるからです。
4. 迅速かつ効率的な応答：応答をキャッシュする能力のおかげで、GETメソッドは繰り返しのリクエストに迅速に対応することができます。それは、各本の場所を正確に知っている整理された図書館員のようなものです。

しかし、制限もあります：

1. メモのスペースが限られている：URLには情報を格納するためのスペースが限られています。それは小さな索引カードに書くようなものです。
2. 秘密はない：URLは可視であり、保存される可能性があるため、それに機密情報を書き込むべきではありません。
3. 干渉しない：観察者は観察対象に影響を与えません。したがって、GETメソッドを使用してデータを変更するべきではありません。それには、私たちのデジタルツールボックスに他のツールがあります。

全体として、GETメソッドはデジタル空間での信頼性のある、そして必要不可欠なツールであり、情報を効率的かつ安全に取得するのに役立ちます。