PUT

PUTメソッドは、ターゲットリソースの状態を、リクエストメッセージペイロードに含まれる表現で定義された状態に作成または置き換えることを要求します。与えられた表現のPUTが成功した場合、同じターゲットリソースに対するその後のGETは、200(OK)応答で同等の表現が送信されることを示唆するでしょう。しかしながら、そのような状態変化が観測可能であるという保証はない。なぜなら、ターゲットリソースは並行して他のユーザーエージェントによって操作されるかもしれないし、後続のGETが受信される前にオリジンサーバーによって動的に処理されるかもしれないからである。

成功した応答は、オリジンサーバーによって処理された時点でユーザーエージェントの意図が達成されたことを意味するだけです。

ターゲットリソースが現在の表現を持たず、PUTがその表現の作成に成功した場合、オリジンサーバーは201 (Created)応答を送信することでユーザーエージェントに通知しなければなりません (MUST)。

ターゲットリソースが現在の表現を持ち、その表現が同封された表現の状態に従って正常に修正された場合、オリジンサーバーはリクエストの正常な完了を示すために200(OK)または204(No Content)応答のいずれかを送信しなければなりません(MUST)、

オリジンサーバーは、PUT表現が、サーバーがターゲットリソースに対して持つ、PUTによって変更できない、または変更されない制約と一貫していることを検証すべきです(SHOULD)。これは、オリジンサーバーがGET応答の表現メタデータの値を設定するために、URIに関連する内部設定情報を使用する場合に特に重要です。PUTの表現がターゲットリソースと矛盾している場合、オリジンサーバーは、 表現を変換するかリソース設定を変更することでそれらを矛盾のないものに するか、表現が不適切である理由を説明するのに十分な情報を含む適切な エラーメッセージで応答するべきである[SHOULD]。409(Conflict)または415(Unsupported Media Type)ステータスコードが推奨され、後者はContent-Type値の制約に特有のものです。

例えば、ターゲットリソースが常に "text/html "のContent-Typeを持つように設定され、PUTされる表現が "image/jpeg "のContent-Typeを持つ場合、オリジンサーバーは次のいずれかを行うべきです:

• a.新しいメディアタイプを反映するためにターゲットリソースを再構成する。
• b. 新しいリソースの状態として保存する前に、PUT表現をリソースのそれと一致するフォーマットに変換する。
• c.ターゲットリソースが "text/html "に制限されていることを示す415(Unsupported Media Type)応答でリクエストを拒否する。

HTTPは、ユーザーエージェントリクエストの意図とオリジンサーバー応答のセマンティクスによって表現される以上に、PUTメソッドがオリジンサーバーの状態にどのように影響するかを正確に定義していません。HTTPを介して提供されるインターフェイスを超えて、リソースの意味するところを定義しない。リソースの状態がどのように "保存 "されるのか、リソースの状態の変化の結果としてそのような保存がどのように変化するのか、オリジンサーバーがリソースの状態をどのように表現に変換するのかを定義しません。

オリジンサーバーは、リクエストの表現データがボディに変換を適用せずに保存され(つまり、リソースの新しい表現データはPUTリクエストで受け取った表現データと同一である)、バリデータフィールド値が新しい表現を反映しない限り、PUTの成功応答でETagやLast-Modifiedフィールドのようなバリデータヘッダーフィールド(セクション7.2)を送信してはなりません(MUST NOT)。この要件により、ユーザーエージェントは、PUTの結果としてメモリにある表現ボディがいつ最新であるかを知ることができ、オリジンサーバーから再度取得する必要がなくなります。また、応答で受け取った新しいバリデータは、偶発的な上書きを防ぐために、将来の条件付きリクエストに使用することができます（セクション5.2）。POSTリクエストにおけるターゲットリソースは、リソース自身のセマンティクスに従って囲まれた表現を扱うことを意図しているのに対して、PUTリクエストにおける囲まれた表現はターゲットリソースの状態を置き換えるものとして定義されています。

PUTリクエストの適切な解釈は、ユーザーエージェントがどのターゲットリソースが望まれているかを知っていることを前提とします。状態を変更するリクエストを受け取った後、クライアントに代わって適切なURIを選択するサービスは、PUTではなくPOSTメソッドを使用して実装されるべきです(SHOULD)。オリジンサーバーが要求されたPUT状態変更をターゲットリソースに行わず、代わりにリソースが異なるURIに移動された場合など、異なるリソースに適用されることを望む場合、オリジンサーバーは適切な3xx(Redirection)応答を送らなければなりません(MUST)。例えば、アーティクルは「現在のバージョン」(リソース)を特定するためのURIを持つかもしれませんが、それは各特定のバージョン(ある時点で現在のバージョンリソースと同じ状態を共有した異なるリソース)を特定するURIとは別のものです。

与えられたターゲットリソース上でPUTを許可するオリジンサーバーは、Content-Rangeヘッダーフィールド(【RFC7233】のセクション4.2)を含むPUTリクエストに対して400(Bad Request)応答を送らなければなりません(MUST)。コンテンツの部分的な更新は、より大きなリソースの一部と重複する状態を持つ、別個に識別されたリソースを対象とするか、部分的な更新のために特別に定義された別のメソッド(例えば[RFC5789]で定義されたPATCHメソッド)を使用することで可能です。

PUTメソッドへの応答はキャッシュできません。成功したPUTリクエストが、有効なリクエストURIに対して一つ以上の 保存された応答を持つキャッシュを通過する場合、それらの保存された 応答は無効にされる(参考文献[RFC7234]のセクション4.4参照)。