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

On 8/1/07, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Aug 1, 2007, at 12:02 PM, Mark Baker wrote:
> > 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?
>
> Do you mean indicated by 200 and (Content-Location == Request-URI)?

As a means to indicate the special case, yes, that's what I was
thinking and mentioned to James.  I wasn't aware of the problem you
pointed out below though ...

> Or a new 2xx status code that specifically says the enclosed response
> entity is as if it were a response to GET on the new state?

That would be fine with me.  But earlier you said;

"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"

So to be clear, are you now suggesting that a 200 PATCH response would
*not* have this specific meaning, and that only this new response code
would indicate that it did have it?  If so, great, we're in sync.

>  I would
> prefer a new response code at this point, since experience has shown
> that content-location is difficult to reconstruct in the presence of
> intermediaries.

Interesting, I wasn't aware of that.

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 20:45:52 UTC