[10] GET は、対象資源を転送することを要求する HTTP 要求メソッドです。

[12] GET は HTTP における最も重要で基本的なメソッドです。 単に HTTP によってアクセスするというとき、ほとんどの場合は GET 要求を送信して応答を受け取ることをいいます。

仕様書

意味

[11] GET メソッドは、対象資源の現在の選択されている表現を転送することを要求するものです >>9。

[13] Range: ヘッダーを要求に含めることで、 GET 要求は範囲要求となり、 選択された表現の部分を転送することを要求するものとなります >>9。

構文

[14] GET 要求の payload の意味は、定義されていません >>9。

[15] 実装によってはそのような要求を却下するものもあります >>9。

[23] これは要求メソッドに依存しないメッセージの構文解析のために規定を緩和したもの >>24 とされています。しかし RFC 2616 のどこでそのような制限が規定されていたのか不明です。

[35] XMLHttpRequest および Request では、要求の payload body を指定することはできません >>33, >>34。

[31] 一般的には GET 要求の payload body の指定は使われておらず、クライアントも対応していないものが大多数と思われます。 しかし、中にはこれを使っているもの (例えば >>30) もあります。 相互運用性のためには payload body は使うべきではありません。

[32] HTTP 仕様も明示的に禁止すれば良いものを、なぜ敢えて「undefined」 のような曖昧な状態にするのでしょうね。仕様が曖昧で相互運用性の問題を放置するなら、 標準化の意義は一体何なのでしょうか。

文脈

[27] HTTP/0.9 では GET が唯一認められている要求メソッドとなっています >>26。

性質

[20] 一般目的の HTTP 鯖は、 GET を実装しなければなりません >>19。

[4] GET は、安全なメソッド >>3 で、 冪等なメソッドです >>5。

[7] GET は、キャッシュ可能です >>6, >>9。 キャッシュは、 Cache-Control: によって別途指定がない限り、 GET 要求に対する応答を以後の GET や HEAD の処理のために使って構いません >>9。

[21] POST に対する応答が GET 要求の処理に使われることがあります。

POST の項を参照してください。

[22] HEAD に対する応答によって既存の HEAD に対する応答のキャッシュが影響されることがあります。

処理

[29] WebDAV コレクションに対する GET では、 (WebDAV でない資源と同じく) 任意の内容を返すことができます >>28。

歴史

[16] RFC 1945 (HTTP/1.0) 8.1; RFC 2068・2616 (HTTP/1.1) 9.3 GET

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

GET 方式は、 Request-URI でどんな (実体の形の) 情報が識別されるのであれ、それを取り出すことを意味します。 Request-URI がデータ生成過程を指しているのであれば、 応答で実体として返されるものは生成されたデータであって、 その過程の原始文ではありません。 (その原始文が過程の出力であったりする場合を除いて。)

The semantics of the GET method changes to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the identified resource entity be transferred only if it has been modified since the date given by the If-Modified-Since header, as described in Section 10.9 under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring unnecessary data data already held by the client.

GET 方式の意味は、要求メッセージが If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, あるいは If-Range 頭欄を含んでいるときは 「条件付 GET」に変わります。 条件付 GET 方式は、実体が条件頭欄(群)で説明される状況にあるときにのみ実体を転送することを要求します。 条件付 GET 方式は、キャッシュされた実態を複数の要求を必要としたり既にクライアントが持っているデータを転送したりせずに更新することを可能とし、 不必要なネットワーク使用を削減することを意図したものです。

The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred, as described in section 14.36 14.35. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client.

要求メッセージが Range 頭欄を含んでいる時、 GET 方式の意味は「部分 GET」 に変わります。 部分 GET 要求は、実体の一部のみを転送します。 部分 GET 方式は、部分的に取り出した実体を、クライアントが既に持っているデータを転送せずに完全にすることを可能とし、不必要なネットワーク使用を削減することを意図しています。

The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13.

GET 要求への応答は、13章で説明している HTTP キャッシュ要件に合致すれば、 その場合に限って、キャッシュ可能です。

See section 15.1.3 for security considerations when used for forms.

フォームでの使用時の安全性についての考察 15.1.3節をご覧あれ。

[17] RFC 2324 (HTCPCP/1.0) 2.1.2 GET method

In HTTP, the GET method is used to mean "retrieve whatever information (in the form of an entity) identified by the Request-URI." If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

HTTP では、 GET method は「(実体の形で) Request-URI で識別される何かの情報を取り出す」ことを意味するのに使っています。 Request-URI がデータ生産過程を参照しているなら、 応答で実体として返されるのは処理したデータであって、 (処理の原始文が処理の出力でない限り) 処理の原始文ではありません。

In HTCPCP, the resources associated with a coffee pot are physical, and not information resources. The "data" for most coffee URIs contain no caffeine.

HTCPCP では、珈琲ポットと関連付けられた資源は物理的存在であり、 情報資源ではありません。 ほとんどの珈琲 URI の「データ」はカフェインを含みません。

関連

[18] HEAD は、 GET の応答のうちヘッダー部分のみの転送を要求するものです。

メモ

[1] GET でも実体を要求メッセージに含めることはできます。 が、世間からは忘れ去られているのでしょうか。。。

[30] Request Body Search ( 版) http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-body.html

Both HTTP GET and HTTP POST can be used to execute search with body. Since not all clients support GET with body, POST is allowed as well.

[37] HTML Standard ( 版) https://html.spec.whatwg.org/#concept-http-equivalent-get

The HTTP GET method is equivalent to the default retrieval action of the protocol. For example, RETR in FTP. Such actions are idempotent and safe, in HTTP terms.

[38] Fix #44 in a better way. (Avoid "extracting" undefined.) · whatwg/fetch@b33de72 ( 版) https://github.com/whatwg/fetch/commit/b33de725823d1a2ab99708b717e83112e4ebeb6b

[39] Also throw when new Request() is passed a Request instance with a non-nu... · whatwg/fetch@5be0642 ( 版) https://github.com/whatwg/fetch/commit/5be0642d1ad5b93ed8467ea9acc28f5786981599

[40] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-8.5