- From: James M Snell <jasnell@gmail.com>
- Date: Thu, 28 Jun 2007 10:47:59 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: LMM@acm.org, 'Henrik Nordstrom' <henrik@henriknordstrom.net>, 'Lisa Dusseault' <ldusseault@commerce.net>, ietf-http-wg@w3.org
Julian Reschke wrote: >>[snip[ >> Don't make this optional. The server shouldn't send the modified >> entity unless the client needs it, and the server has no way to >> determine whether the client needs it. And the client can ask >> for it by doing a GET. >> >> Behavior should be predictable, and the fewer options you have, >> the better. > > +1. > > In the general case PATCH either fails with 4xx (Conflict) or succeeds. > In the latter case, a client can always send a subsequent GET. > The only challenge with this is that the whole point of returning the entity in the response is to verify that the resource was patched successfully. If the resource is modified between the time the PATCH response is received and a subsequent GET is issued, then verifying the result becomes problematic. Using Etags we can obviously detect the subsequent change, but it's harder to verify that our specific change was applied correctly. For byte/character based deltas, this is not so much of a problem. For structural deltas it can be a significant problem. - James
Received on Thursday, 28 June 2007 17:48:11 UTC