Re: PATCH Draft

Lisa Dusseault wrote:
> [snip]
>>
>> "The server MUST NOT create a new resource with the contents of the
>> request body"
>>
>> Why not?  I don't see the problem.
> 
> This is to require that the server not treat the PATCH like a PUT.  If
> there's a way to *apply* the patch to an empty body that might be fine,
> but the server should not save the delta algorithm as the resource body.
> If that's what the client wanted, it would do a PUT.
> 

Yes. However, that is different than creating a new resource as the
result of applying a patch.  I think we need to be clear that it is ok
for the application of the patch to result in the creation of a resource
but, as you say, the server should not save the payload of the patch
request as the content of that new resource.

>>[snip]
>> "Therefore, the client MUST verify that it is applying the delta
>> encoding to a known entity by first acquiring the strong ETag [...]"
>>
>> I don't see why this is required.  Of course, if the client wants the
>> guarantees provided by strong etags, it can get them.  But why does
>> that matter to a protocol specification?  Suggest removal of that
>> paragraph.
> 
> Why remove it?  What's the harm in making this requirement that clients
> behave properly?
> 

Well, this requirement is predicated on the idea that the resource being
patched already exists.  If we allow the application of the patch to
result in the creation of a new resource, then it obviously cannot rely
on the use of strong etags.  I would suggest making this a SHOULD rather
than a MUST.

>> I suggest the use of 422 instead of 400 in the "malformed delta
>> encoding" case of sec 2.2.2.
> 
> What's 422?

422 Unprocessable Entity from RFC2518.

   The 422 (Unprocessable Entity) status code means the server
   understands the content type of the request entity (hence a
   415(Unsupported Media Type) status code is inappropriate), and the
   syntax of the request entity is correct (thus a 400 (Bad Request)
   status code is inappropriate) but was unable to process the contained
   instructions.  For example, this error condition may occur if an XML
   request body contains well-formed (i.e., syntactically correct), but
   semantically erroneous XML instructions.

The malformed delta encoding response assumes that the syntax of the
delta encoding is incorrect, which would make a 400 response
appropriate.  According to the text of 422, the syntax of the request is
assumed to be correct but still cannot be applied for whatever reason.

> 
>>
>> Sec 2.3 seems to over specify a few things.  For example, the Allow
>> response header isn't required to list "all the allowed methods" so
>> there's no need for "MUST" there.  I think that all you really need in
>> this section is the definition of the Accept-Patch header.
> 
> The benefit of this requirement is so that clients can count on the
> Allow header for at least this case.  What's the harm of this requirement?
> 

I don't see the harm in having it, but I also don't see any harm in
making it a SHOULD.  The presence of an Accept-Patch header in an
OPTIONS, GET, or HEAD response for a given resource will likely be
enough of a clue that the server supports the PATCH method for that
resource.

- James

Received on Wednesday, 4 July 2007 22:04:56 UTC