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
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
