9. Method Definitions (メソッド定義)

HTTP/1.1の一般的なメソッドセットを以下に定義します。このセットは拡張可能ですが、個別に拡張されたクライアントとサーバーで追加のメソッドが同じセマンティクスを共有すると想定することはできません。

Hostリクエストヘッダフィールド（第14.23節）は、すべてのHTTP/1.1リクエストに付随しなければなりません (MUST)。

9.1 Safe and Idempotent Methods (安全性とべき等性のあるメソッド)

9.1.1 Safe Methods (安全なメソッド)

実装者は、ソフトウェアがユーザーに代わってインターネット上でやり取りを行うこと、およびユーザー自身または他者に対して予期しない意味を持つ可能性のあるあらゆる行動についてユーザーに認識させるよう注意すべきであることを認識すべきです。

特に、GETおよびHEADメソッドは、検索以外の操作上の意味を持つべきではない (SHOULD NOT) という確立された慣習があります。これらのメソッドは「安全」(safe) と見なされるべきです。これにより、ユーザーエージェントは、POSTやPUT、DELETEなどの他のメソッドを特別な方法で表現し、安全でない可能性のある操作が要求されていることをユーザーに認識させることができます。

当然ながら、GETリクエストを実行する際にサーバーが副作用を生じさせないことを保証することはできません。実際、一部の動的リソースはこれを機能と見なしています。ここでの重要な区別は、ユーザーが副作用を要求していないため、それに対して責任を負えないということです。

9.1.2 Idempotent Methods (べき等メソッド)

メソッドは「べき等性」(idempotence) の特性を持つこともできます。つまり、（エラーや有効期限の問題を除いて）N > 0 個の同一のリクエストの副作用は、単一のリクエストと同じです。メソッドGET、HEAD、PUT、DELETEはこの特性を共有します。さらに、メソッドOPTIONSとTRACEは副作用を持つべきではない (SHOULD NOT) ため、本質的にべき等です。

ただし、一連の複数のリクエストが非べき等である可能性があります。たとえば、結果または任意のリソースの状態がシーケンス内の複数のリクエストに依存する場合などです。POSTリクエストはべき等ではありません。

9.2 OPTIONS

OPTIONSメソッドは、リクエスト-レスポンスチェーンで利用可能な通信オプションに関する情報のリクエストを表します。このメソッドにより、クライアントは、リソース操作を暗示したりリソース検索を開始したりすることなく、リソースに関連するオプションおよび/または要件、またはサーバーの機能を判断できます。

このメソッドへのレスポンスはキャッシュ可能ではありません。

OPTIONSリクエストにエンティティボディが含まれている場合（Content-LengthまたはTransfer-Encodingの存在によって示される）、メディアタイプをContent-Typeフィールドで示さなければなりません (MUST)。この仕様ではこのようなボディの使用を定義していませんが、将来のHTTP拡張では、OPTIONSボディを使用してサーバーにより詳細なクエリ情報を提供する可能性があります。このような拡張をサポートしていないサーバーは、リクエストボディを破棄できます (MAY)。

Request-URIがアスタリスク（""）の場合、OPTIONSリクエストは通常、特定のリソースではなくサーバーに適用されます。サーバーの通信オプションは通常リソースに依存するため、""リクエストは「ping」または「no-op」タイプのメソッドとしてのみ有用です。クライアントがサーバーの機能をテストできるようにする以外には何も行いません。たとえば、これはプロキシのHTTP/1.1準拠（または非準拠）をテストするために使用できます。

Request-URIがアスタリスクでない場合、OPTIONSリクエストは、そのリソースとの通信時に利用可能なオプションにのみ適用されます。

200レスポンスには、そのリソースに適用される場合（例：Allow）、オプション機能を示す任意のヘッダフィールドを含むべき (SHOULD) です。この仕様で定義されていない拡張を含む可能性があります。レスポンスボディが含まれている場合、それは通信オプションに関する情報を含むべき (SHOULD) です。この仕様ではそのボディの形式を定義していませんが、HTTPの将来の拡張で定義される可能性があります。コンテンツネゴシエーションを使用して、適切なレスポンス形式を選択できます。レスポンスボディが含まれていない場合、レスポンスには、フィールド値が"0"のContent-Lengthフィールドを含まなければなりません (MUST)。

Max-Forwardsリクエストヘッダフィールドを使用して (MAY)、リクエストチェーン上の特定のプロキシにリクエストをターゲティングできます。プロキシがリクエストの転送を許可するOPTIONSリクエストを受信した場合、プロキシはMax-Forwardsフィールドをチェックしなければなりません (MUST)。Max-Forwardsフィールド値がゼロ（"0"）の場合、プロキシはメッセージを転送してはなりません (MUST NOT)。代わりに、プロキシは自身の通信オプションで応答すべき (SHOULD) です。Max-Forwardsフィールド値がゼロより大きい整数の場合、プロキシはフィールド値をデクリメントし、リクエストを次のホップサーバーに転送しなければなりません (MUST)。OPTIONSリクエストにMax-Forwardsフィールドが存在しない場合、転送プロキシはMax-Forwardsフィールドを追加してはなりません (MUST NOT)。

9.3 GET

GETメソッドは、Request-URIで識別される任意の情報（エンティティの形式で）の検索を表します。Request-URIがデータ生成プロセスを参照する場合、そのテキストがプロセスの出力である場合を除き、プロセスのソーステキストではなく、生成されたデータをレスポンスのエンティティとして返すべきです。

リクエストメッセージにIf-Modified-Since、If-Unmodified-Since、If-Match、If-None-Match、またはIf-Rangeヘッダフィールドが含まれている場合、GETのセマンティクスは「条件付きGET」(conditional GET) に変更されます。条件付きGETメソッドは、条件ヘッダフィールドで記述された状況下でのみエンティティを転送するよう要求します。条件付きGETメソッドは、複数のリクエストやクライアントがすでに保持しているデータの転送を必要とせずに、キャッシュされたエンティティをリフレッシュできるようにすることで、不要なネットワーク使用を削減することを目的としています。

リクエストメッセージにRangeヘッダフィールドが含まれている場合、GETのセマンティクスは「部分的GET」(partial GET) に変更されます。部分的GETは、第14.35節で説明されているように、エンティティの一部のみを転送するよう要求します。部分的GETメソッドは、クライアントがすでに保持しているデータを転送せずに、部分的に検索されたエンティティを完成できるようにすることで、不要なネットワーク使用を削減することを目的としています。

GETリクエストへのレスポンスは、第13節で説明されているHTTPキャッシング要件を満たす場合にのみキャッシュ可能です。

GETおよびHEADメソッドの特別な考慮事項については、第15.1.3節のセキュリティ考慮事項を参照してください。

9.4 HEAD

HEADメソッドはGETと同一ですが、サーバーがレスポンスでメッセージボディを返してはならない (MUST NOT) 点が異なります。HEADリクエストへのレスポンスのHTTPヘッダに含まれるメタ情報は、GETリクエストへのレスポンスとして送信される情報と同じであるべき (SHOULD) です。このメソッドは、エンティティボディ自体を転送せずに、リクエストが暗示するエンティティに関するメタ情報を取得するために使用できます。このメソッドは、ハイパーテキストリンクの有効性、アクセシビリティ、および最近の変更をテストするためによく使用されます。

HEADリクエストへのレスポンスは、レスポンスに含まれる情報を使用してそのリソースから以前にキャッシュされたエンティティを更新できるため、キャッシュ可能である場合があります (MAY)。新しいフィールド値が、キャッシュされたエンティティが現在のエンティティと異なることを示す場合（Content-Length、Content-MD5、ETag、またはLast-Modifiedの変更で示される）、キャッシュはキャッシュエントリを古いものとして扱わなければなりません (MUST)。

9.5 POST

POSTメソッドは、オリジンサーバーがリクエストに含まれるエンティティを、Request-URIで識別されるリソースの新しい従属として受け入れるよう要求するために使用されます。POSTは、以下の機能をカバーする統一的なメソッドを可能にすることを目的としています：

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

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

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

リソースがオリジンサーバー上に作成された場合、レスポンスは201（Created）であるべき (SHOULD) で、リクエストのステータスを記述し、新しいリソースを参照するエンティティと、Locationヘッダ（第14.30節を参照）を含みます。

このメソッドへのレスポンスは、レスポンスに適切なCache-ControlまたはExpiresヘッダフィールドが含まれていない限り、キャッシュ可能ではありません。ただし、303（See Other）レスポンスを使用して、ユーザーエージェントにキャッシュ可能なリソースを取得するよう指示できます。

POSTリクエストは、第8.2節で説明されているメッセージ転送要件に従わなければなりません (MUST)。

POSTメソッドのキャッシング考慮事項については、第13.4節を参照してください。

9.6 PUT

PUTメソッドは、含まれるエンティティを提供されたRequest-URIの下に保存するよう要求します。Request-URIが既存のリソースを参照している場合、含まれるエンティティは、オリジンサーバー上に存在するそのリソースの変更版と見なされるべきです。Request-URIが既存のリソースを指していない場合で、そのURIがリクエストするユーザーエージェントによって新しいリソースとして定義できる場合、オリジンサーバーはそのURIでリソースを作成できます (can)。新しいリソースが作成された場合、オリジンサーバーは201（Created）レスポンスでユーザーエージェントに通知しなければなりません (MUST)。既存のリソースが変更された場合、リクエストの正常完了を示すために200（OK）または204（No Content）レスポンスコードを送信すべき (SHOULD) です。Request-URIでリソースを作成または変更できない場合、問題の性質を反映する適切なエラーレスポンスを提供すべき (SHOULD) です。エンティティの受信者は、理解または実装していない任意のContent-*（例：Content-Range）ヘッダを無視してはならず (MUST NOT)、そのような場合は501（Not Implemented）レスポンスを返さなければなりません (MUST)。

リクエストがキャッシュを通過し、Request-URIが現在キャッシュされている1つ以上のエンティティを識別している場合、それらのエントリは古いものとして扱われるべき (SHOULD) です。このメソッドへのレスポンスはキャッシュ可能ではありません。

PUTとPOSTリクエストの基本的な違いは、Request-URIの異なる意味に反映されています。POSTリクエストのURIは、含まれるエンティティを処理するリソースを識別します。そのリソースは、データ受け入れプロセス、他のプロトコルへのゲートウェイ、または注釈を受け入れる別個のエンティティである可能性があります。対照的に、PUTリクエストのURIは、リクエストに含まれるエンティティを識別します。ユーザーエージェントは意図するURIを知っており、サーバーはリクエストを他のリソースに適用しようとしてはなりません (MUST NOT)。サーバーがリクエストを別のURIに適用したい場合、301（Moved Permanently）レスポンスを送信しなければなりません (MUST)。その後、ユーザーエージェントは、リクエストをリダイレクトするかどうかを自分で決定できます (MAY)。

単一のリソースは、多くの異なるURIによって識別される場合があります。たとえば、記事には、各特定のバージョンを識別するために使用されるURIとは異なる「現在のバージョン」を識別するために使用されるURIがある場合があります。この場合、一般的なURIへのPUTリクエストにより、オリジンサーバーによって他のURIが定義される可能性があります。

HTTP/1.1は、PUTメソッドがオリジンサーバーの状態にどのように影響するかを定義していません。

PUTリクエストは、第8.2節で説明されているメッセージ転送要件に従わなければなりません (MUST)。

特別な要件がない限り、PUTメソッドの副作用は、同じRequest-URIでGETリクエストを送信した場合の副作用と同じであるべき (SHOULD) です。

9.7 DELETE

DELETEメソッドは、Request-URIで識別されるリソースをオリジンサーバーが削除するよう要求します。このメソッドは、オリジンサーバー上で人間による介入（または他の手段）によってオーバーライドされる場合があります (MAY)。オリジンサーバーから返されたステータスコードが操作が正常に完了したことを示していても、クライアントは操作が実行されたことを保証できません。ただし、サーバーは、レスポンスを提供する時点でリソースを削除するかアクセス不可能な場所に移動する意図がない限り、成功を示すべきではありません (SHOULD NOT)。

操作が正常に実行されたかどうかを知ることができない場合でも、成功したレスポンスは、操作が正常に実行された可能性が高い場合は200（OK）、操作がまだ実行されていない場合は202（Accepted）、または操作が実行されたがレスポンスにエンティティが含まれていない場合は204（No Content）であるべき (SHOULD) です。

リクエストがキャッシュを通過し、Request-URIが現在キャッシュされている1つ以上のエンティティを識別している場合、それらのエントリは古いものとして扱われるべき (SHOULD) です。このメソッドへのレスポンスはキャッシュ可能ではありません。

9.8 TRACE

TRACEメソッドは、ターゲットリソースへのパスに沿ったリクエストメッセージのリモートアプリケーション層ループバックを呼び出すために使用されます。最終受信者へのリクエストは、受信したメッセージを200（OK）レスポンスのエンティティボディとしてクライアントに反映すべき (SHOULD) です。最終受信者は、オリジンサーバー、またはMax-Forwards値がゼロ（0）のリクエストを受信した最初のプロキシまたはゲートウェイです（第14.31節を参照）。TRACEリクエストにはエンティティを含めてはなりません (MUST NOT)。

TRACEにより、クライアントはリクエストチェーンの反対側で受信されている内容を確認でき、そのデータをテストまたは診断情報に使用できます。Viaヘッダフィールド（第14.45節）の値は、リクエストチェーンのトレースとして機能するため、特に興味深いものです。Max-Forwardsヘッダの使用により、クライアントはリクエストチェーンの長さを制限できます。これは、無限ループでメッセージを転送するプロキシチェーンをテストする際に便利です。

リクエストが有効な場合、レスポンスは、Content-Typeが "message/http" のエンティティボディに完全なリクエストメッセージを含むべき (SHOULD) です。このメソッドへのレスポンスはキャッシュしてはなりません (MUST NOT)。

9.9 CONNECT

この仕様では、動的にトンネルに切り替えることができるプロキシで使用するためのメソッド名CONNECTを予約しています（例：SSLトンネル [44]）。

---