POST vs. PUT Re: [uf-rest] REST opacity and URL schemes.

[Mark Nottingham]

Can someone illustrate with what the messages might look like on the  
wire? I'm not a Rails person...

Cheers,


On 2006/04/24, at 12:03 PM, Dr. Ernie Prabhakar wrote:

> Hi Mark,
>
> On Apr 24, 2006, at 11:57 AM, Mark Nottingham wrote:
>> Let's not rush into things. Part of the value of PUT is that it  
>> has a particular meaning (as used in WebDAV and elsewhere).
>>
>> Turn it around for a moment; what are the use cases where PUT is  
>> useful over POST for something where you can't GET back the  
>> representation you just sent? If you're using PUT to do something  
>> like update part of a representation, rather than the whole thing,  
>> will it really be idempotent? Why not surface the thing as a  
>> separate URI?
>
> I think the key that convinced me is that the way Rails is using PUT:
>
> a) The PUT has all the "extrinsic" information needed to create the  
> resource
>
> That is, even if there are some "synthetic" fields created  
> internally, or after the fact, by the server, they are not user- 
> visible.  In other words, the request really _does_ contain all the  
> user-visible attributes.
>
> b) No caching mechanisms should be using PUT to implement a write- 
> through cache.
>
> That is, if I understand Dan's citation of the spec properly, there  
> is NO guarantee that the PUT is syntactically identical to the GET  
> of the same content-type of that resource.   As such, we only care  
> about semantic equivalent, not syntactic exactitude.
>
> At least, that's the most my poor brain can deduce on a Monday  
> morning.  Hopefully some of the experts will weigh in.
>
> And thanks for asking -- this is a gnarly topic, and greater  
> clarity would be a very useful thing!
>
> -- Ernie P.
>
>
>>
>> Cheers,
>>
>>
>> On 2006/04/24, at 11:49 AM, Dr. Ernie Prabhakar wrote:
>>
>>> Dan & Charlie,
>>>
>>> On Apr 22, 2006, at 10:43 PM, Dan Kubb wrote:
>>>> So this means that POST is a way of sending data to a resource
>>>> that handles the request directly and/or can delegate the handling
>>>> to something else at its discretion.  PUT is a way of changing
>>>> the state of a resource explicitly identified by its URI.
>>>
>>> Ah, very interesting.  My understanding was closer to Mark's:
>>>
>>>> My rule of thumb for PUT is that afterwards, if I GET a  
>>>> representation from the same resource, it should give me back  
>>>> what I sent in the first place (unless it's been separately  
>>>> changed in the meantime). You also have to account for transcoding.
>>>
>>> But, if I'm following your argument, that is actually a  
>>> _mis_understanding on my part.  Very interesting.
>>>
>>> Okay,  if so, that is a nice separation, and David's usage is  
>>> correct, with POST-as-POST being reserved for RPC-style calls  
>>> with side-effects.  I'll update the wiki accordingly:
>>>
>>> http://microformats.org/wiki/rest/rails#Simply_RESTful
>>>
>>> The other issue with PUT vs. POST is that the error/return codes  
>>> are different, no? Does either plug-in currently handle those  
>>> correctly?
>>>
>>> -- Ernie P.
>>>
>>>
>>> _______________________________________________
>>> microformats-rest mailing list
>>> microformats-rest at microformats.org
>>> http://microformats.org/mailman/listinfo/microformats-rest
>>>
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>> _______________________________________________
>> microformats-rest mailing list
>> microformats-rest at microformats.org
>> http://microformats.org/mailman/listinfo/microformats-rest
>
> _______________________________________________
> microformats-rest mailing list
> microformats-rest at microformats.org
> http://microformats.org/mailman/listinfo/microformats-rest
>
>

--
Mark Nottingham
mnot at yahoo-inc.com