Question: Reading [this page](http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html), it says:

> 
> ...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.
> 
> 
> 

From this I gather that I should not have a URL exposed which accepts PUT requests where the URL does not uniquely identify a resource. e.g.:

```
http://www.example.com/cars

```

Rather, I should allow PUT requests on the following URL:

```
http://www.example.com/cars/123

```

However, in a PUT request, the content is supposed to contain the entire entity, which could, therefore, contain some sort of primary key (like the `123` in the above URL). So is it really considered bad practice to expose non-unique URLs for PUT requests when the content will contain the unique identifier? In my service, all I want to do is collect data from clients, so a RESTful service accepting PUT requrests is great, but I don't really want to have the URL being unique (as this means more work to construct the URL on the client side).

Answer: 
PUT should only be used when the client knows for sure the resulting resource that should contain the entity after the request completes.

If you are simply collecting data from clients, then likely you should be using POST instead.
That is why in REST semantics, the PUT is used for updates and to create any resource you are supposed to be using POST.