"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 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.
".. 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. That resource 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 MUST NOT attempt to apply the request to some other resource."
RFC2616[1] Fielding, et al.
This is a key part of the spec, and you can see Dr. Fielding's intentions in REST. Specific URI 's referring to a Representation of an entity is a core architectural component of REST[2].
colanderman is correct in his reply. Although RFCs are designed to be very explicit, certain sections are all too often left open to interpretation when vague/ambiguous language is used.
This is not one of those times. It is very clearly defined that PUT, by design, creates a resource at the exact URL provided. The 307 redirect variant mentioned is over-complicating the scenario. The right thing to do is use POST and return 201 Created with a Location header to the created URL.
Just because it works as-is doesn't mean there isn't a better way that strictly follows expected behaviors.
