After that discussion, a more realistic mapping would seem to be:
* Create = PUT iff you are sending the full content of the specified resource (URL).
* Create = POST if you are sending a command to the server to create a subordinate of the specified resource, using some server-side algorithm.
* Retrieve = GET.
* Update = PUT iff you are updating the full content of the specified resource.
* Update = POST if you are requesting the server to update one or more subordinates of the specified resource.
* Delete = DELETE.
I am not sure about "Update = POST if you are requesting the server to update one or more subordinates of the specified resource" - seems to me that if the subordinate updates are idempotent - then this can be PUT, why not. But going a bit further - of all the server side algorithms used for Create calls the most used one is computing the primary keys for auto increment columns. So if you are not using some special database functions - a Create needs to be POST if the primary key is auto-increment and can be PUT otherwise.
In regards to the Update PUT vs Update POST, with the PUT you can only address a single resource. So while the Update POST maybe idempotent, to accomplish the same thing with a PUT, you would have to issue multiple PUTs to address all of the resources that were updated in the POST.
Comments
His key point:
After that discussion, a more realistic mapping would seem to be:
* Create = PUT iff you are sending the full content of the specified resource (URL).
* Create = POST if you are sending a command to the server to create a subordinate of the specified resource, using some server-side algorithm.
* Retrieve = GET.
* Update = PUT iff you are updating the full content of the specified resource.
* Update = POST if you are requesting the server to update one or more subordinates of the specified resource.
* Delete = DELETE.
I am not sure about "Update = POST if you are requesting the server to update one or more subordinates of the specified resource" - seems to me that if the subordinate updates are idempotent - then this can be PUT, why not. But going a bit further - of all the server side algorithms used for Create calls the most used one is computing the primary keys for auto increment columns. So if you are not using some special database functions - a Create needs to be POST if the primary key is auto-increment and can be PUT otherwise.
In regards to the Update PUT vs Update POST, with the PUT you can only address a single resource. So while the Update POST maybe idempotent, to accomplish the same thing with a PUT, you would have to issue multiple PUTs to address all of the resources that were updated in the POST.