[uf-rest] REST opacity and URL schemes.

[Mark Nottingham]

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?

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/