- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 26 Jun 2007 12:36:25 +0200
- To: LMM@acm.org
- CC: 'James M Snell' <jasnell@gmail.com>, 'Henrik Nordstrom' <henrik@henriknordstrom.net>, 'Lisa Dusseault' <ldusseault@commerce.net>, ietf-http-wg@w3.org
Larry Masinter wrote: >> The draft already talks about returning the modified entity, with an 200 >> example carrying it.. >> >> If the server do not want to return the modified entity then it can >> return a 204. > > 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. > I'm not entirely convinced that there is a demand for single client > multiple server implementations of PATCH, or that it is viable > without a MTI content-type for patching instructions. Yes. PATCH for atom entries is different from PATCH for arbitrary binary content, and that's different from Yaron's Web3S scenarios (I guess). I don't see how a single patch format would be helpful here... > And if prior out-of-band agreement is needed, then you might as > well just use POST with constructed URLs (http://site/path -> > http://site/PATCHER/path for example), and you'd avoid the > problem of expecting infrastructure that never heard of > PATCH to quickly implement its POST-like caching rules. Could you elaborate on this? If a POST to http://site/PATCHER/path affects the resource at http://site/path (for instance), how is a cache going to find out about that? Best regards, Julian
Received on Tuesday, 26 June 2007 10:36:42 UTC