Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-08.txt]

Hi Roy,

On 8/1/07, Roy T. Fielding <fielding@gbiv.com> wrote:
> > Just from the meaning of PATCH.  It's purpose is just to affect a
> > state change on the server, and isn't requesting that anything
> > specific be returned in the response, just like PUT and POST.
> > Therefore there's no reason to limit the meaning of what might be
> > returned.
>
> That's backwards.  If we had the choice of doing so at the time, PUT
> would have been defined such that 200 responses would be the same as
> if the method had been GET (i.e., return the resulting representation
> after the PUT was applied) and 204 would be success without a body.
> The only reason we did not define it that way is because some of the
> existing, deployed implementations were inconsistent (because they
> were deployed before 204 was available).
>
> We don't have that problem today with PATCH, AFAIK.  There is no
> reason not to define a 200 response to PATCH as being the same as
> the representation that would have been received in a GET response
> after the patch has been successfully applied.  Remember, we aren't
> forcing the server to return 200 -- the server can choose which
> status is returned.

Sure, but if the server wants to signal a successful PATCH, then it's
stuck with 2xx.

What if, for example, a server wanted to respond to a successful PATCH
attempt with a document which revealed (via hyperlinks) a new part of
the application?  I've done this with both PUT and POST (mostly POST)
in several applications I've developed, so can attest to its utility.

What am I missing?  What's the value in restricting the information
that a response message can communicate?  What's wrong with just
treating a response which communicates the state of the resource
post-invocation, as a special case?

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

Received on Wednesday, 1 August 2007 19:02:41 UTC