The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity should SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

PUT 方式は、囲まれた実体を供給した Request-URI の元で蓄積することを要求します。 Request-URI が既に存在する資源を指している時は、 囲まれた実体は起源サーバーにあるものの修正版と考えられるべきです。 Request-URI が既存の資源を指しておらず、 その URI に要求している利用者エージェントによって新しい資源を定義する能力があるなら、 起源サーバーはその URI に資源を作ることが出来ます。 新しい資源が作られたら、起源サーバーは 301 (作成せし) 応答で利用者エージェントに知らせなければなりません。既存の資源が修正されたなら、 200 (了解) または 204 (無内容) の応答符号を送って要求の成功裏完了を示すべきです。その Request-URI で資源を作るか修正するかできなかったときは、問題の性質を反映して適切な誤り応答を与えるべきです。実体の受信者は、その理解・実装しない Content-* 頭 (例えば Content-Range) を無視してはなりませんで、そのような場合には 501 (未実装) 応答を返さなければなりません。

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity {1945} as data to be processed. That resource {1945,2068} may {2616} might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server {1945} should not MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

POST 要求と PUT 要求の本質的な違いは、 Request-URI の違った意味を反映しています。 POST 要求の URI は囲まれた実体を処理されるデータとして取扱う資源を識別します。 その資源はデータ受入れ過程かもしれませんし、他のプロトコルとの関門かもしれませんし、 注釈を受け入れる別の実体かもしれません。 かわって、 PUT 要求の URI は要求に囲まれた実体のを識別します。 利用者エージェントはどの URI が意図されているかを知っており、 サーバーはその要求を他の資源に適用しようと試みてはなりません。サーバーが要求を異なる URI に適用することを望む時は、 301 (永続的移動) 応答を送らなければなりません。利用者エージェントは要求を再指向するかどうかについて自身の決定を下して構いません。

Example setting "y" to 5 in the matching document without affecting other fields (using jQuery):

$.ajax( { url: "https://api.mongolab.com/api/1/databases/my-db/collections/my-coll/4e7315a65e4ce91f885b7dde?apiKey=myAPIKey",

data: JSON.stringify( { "$set" : { "y" : 5 } } ),

type: "PUT",

contentType: "application/json" } );