- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 1 Aug 2007 11:36:35 -0700
- To: Mark Baker <distobj@acm.org>
- Cc: "Lisa Dusseault" <lisa@osafoundation.org>, ietf-http-wg@w3.org
On Jul 31, 2007, at 9:26 PM, Mark Baker wrote: > On 7/31/07, Lisa Dusseault <lisa@osafoundation.org> wrote: >> On Jul 31, 2007, at 9:59 AM, Mark Baker wrote: >>> Hi Lisa, >>> >>> On 7/31/07, Lisa Dusseault <lisa@osafoundation.org> wrote: >>>> If we allow the server to return arbitrary bodies in a 200 response >>>> to a PATCH, we'll have to be very clear on how clients should >>>> handle >>>> the returned information. A caching or synching client might >>>> use the >>>> body as the new representation of the resource regardless of what >>>> headers appeared in the 200 response. >>> >>> That would be a broken client, AFAICT. >> >> Interesting! What's your basis for believing that? > > 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. ....Roy
Received on Wednesday, 1 August 2007 18:36:48 UTC