- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Tue, 26 Jun 2007 00:26:27 +0200
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: James M Snell <jasnell@gmail.com>, ietf-http-wg@w3.org, Lisa Dusseault <lisa@osafoundation.org>
- Message-Id: <1182810387.4708.66.camel@henriknordstrom.net>
mån 2007-06-25 klockan 22:27 +0200 skrev Stefan Eissing: > Personally, I think this is not helpful. PATCH cannot require servers > to support such a format. For every format it is trivial to think of > an application where it does not make sense. Sure, but for interoperability it helps a lot if there is at least one text and one binary format that most clients can expect to be supported on most servers, therefore one or two recommendations on formats to use helps a lot. This do not mean that every server MUST support those formats, or that there SHOULD NOT be any other formats supported. Only that there is an established recommendation on what formats to use unless there is strong reasons not to, in order to make interoperability reasonable. > > * Should it be possible to create new resources with PATCH > > Non-issue in my mind: up to the application. See above. I disagree. Part of this should be in the protocol. Most importanly if it should be possible for the client to ask the server that a new resource should be created based on another "template" resource and a delta. > > * Should it be required to use If-Match and If-Unmodified-Since > > on PATCH. > > Definitely not. Let's say subversion wants to use PATCH, using the > good old diff format on text files. It is definitely counter- > productive to require it to fail on changed ETags when it clearly > does not want to. I'd say it should be a SHOULD requirement unless the delta format in question has it's own conflict resolution. > On the other hand, one can think of applications using PATCH to save > bandwidth. Using some simple binary patch format. Such applications > will make heavy use of If-Match headers and rightly so. Needs to be clearly mentioned, or I'm afraid there will be lots of implementations which overlooks this. > Replace: "The server MUST NOT create a new resource with the contents > of the request body, although it MAY (depending on the delta > encoding) apply the request body to an empty resource." > By: "If the server accepts PATCH on a non-existing resource is up to > the server implementation." > Reason: there may be applications where it makes sense, others might > strictly forbid it. Why? There is already the PUT method for creating entities. Unless we talk about creating a resource from a template + delta ofcourse.. > Idea: Only describe difference of PATCH responses to PUT responses Perhaps. > Idea: should "Accept-Patch" header also appear in responses to PATCH? Yes, I'd say so. The modified resource do not need to support further PATCH modifications, depending on the application. Regards Henrik
Received on Monday, 25 June 2007 22:26:38 UTC