Re: Question regarding POST versus PUT for creating an LDPC

hello all.

On 2013-04-17 3:38 , "Eric Prud'hommeaux" <eric@w3.org> wrote:
>>One area where I'm having doubts is on what might be the more logical
>>HTTP
>> method for the creation of an LDPC. POST or PUT?
>> 
>> I kind of get the feeling that the spec, as it stands, seems to imply
>>that
>> PUT is the better method. But I'm not so sure.
>> 
>> In your experience, is there a convention for CREATE? It just doesn't
>>seem
>> clear to me that one is intended over the other. I suppose both could be
>> supported, but what would be the majority expectation?
>1 PUTting a resource names that aren't cryptographically unique means
>  it's likely that some client has already created that resource,
>  e.g. all clients try all the time to create container/item1.
>2 The server implementation might constrain the names of the resources
>  it can store and serve, e.g. one backed by a database which stores
>  only an integer which it concatonates unto "container/item".

in my experience, people often try to read to much into the method names,
or some patterns how they are used on the web. HTTP has no create. what's
the difference between PUT and POST?

- PUT is idempotent, so retries can be done safely. this often means that
people see it as some form of "client-named create", because once it has
been created, a repeated request is just an overwrite. whatever a service
does, it simply has to be designed in a way that these repeated PUT
requests do not create problems in the service semantics.

- POST is not idempotent, so you cannot just retry a failed request. this
often means that people see it as some form of "server-named create",
because if you do repeat requests, you get multiple things being created.
POST simply means that a client has to be more careful, but it also means
that it would be a good idea to have a recovery strategy for a client
(what to do when the POST request failed).

http://dret.typepad.com/dretblog/2011/11/creating-resources-with-get-put.ht
ml and similar ideas have been developed around how to design "POST
exactly once" semantics for services, but afaict, these service semantics
always are baked into a service's REST interaction model, since there is
no way how you can just magically make them work by choosing one HTTP
method over the other.

cheers,

dret.

Received on Wednesday, 17 April 2013 18:02:18 UTC