The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload. A successful PUT of a given
representation would suggest that a subsequent GET on that same
target resource will result in an equivalent representation being
sent in a 200 (OK) response.
Placing the PUT body at a different location and returning a pointer to it is not supported by this definition. Furthermore:
Proper interpretation of a PUT request presumes that the user agent
knows which target resource is desired. A service that selects a
proper URI on behalf of the client, after receiving a state-changing
request, SHOULD be implemented using the POST method rather than PUT.
If the origin server will not make the requested PUT state change to
the target resource and instead wishes to have it applied to a
different resource, such as when the resource has been moved to a
different URI, then the origin server MUST send an appropriate 3xx
(Redirection) response; the user agent MAY then make its own decision
regarding whether or not to redirect the request.
That is, to get the effect you intend, you should either (a) use POST (from which you should return a 201 with the final destination, not 200 like you currently do), or (b) issue a 307 redirect to the final destination of the PUT before accepting any content (and subsequently replying with a 201).
"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.
[1] http://tools.ietf.org/html/rfc7231#section-4.3.4