Re: PATCH, Expect, Prefer, etc

James M Snell wrote:
>>> The request has succeeded.  The information returned with the response
>>> is equivalent to what would be returned in a subsequent GET on the
>>> resource.
>> This may need to state something about variant selection.
>>
> 
> Likely. Do you have a specific suggestion?

Hm.

Everything is simple as long as the resource addressed by the 
Request-URI doesn't do content negotiation. Maybe it would make sense 
just to require that.

Otherwise we'll have to do some cleanup in the method definition. The 
patch is applied to an entity, not the resource, right. So we probably 
should use the much-loved term "requested variant" from RFC2616, and 
then later on state that the entity returned with a 209 status is the 
new version of the requested variant.

>>> 418 Preference Failed
>>>
>>> The preference given in a Prefer request-header field was understood by
>>> could not be met by this server.
>> I'm not sure this should even be an error condition. Wouldn't it be
>> wiser to just let the server execute the operation? It's "preference",
>> not "expectation", after all.
>>
> 
> Well, the issue here is that it is not clear whether or not the server
> did not understand a preference or just decided not to honor it.  If
> there's no real value in that distinction, then yes, this code is not
> necessary.

I'm not sure it's needed. But if it is needed, a status code won't 
scale. If a request has multiple preferences, and the server only meets 
some of them, something more complex would be needed, such as as 
"Preferences-Met" response header.


>> [snip]
>>> Thoughts?
>> Also, I'd clarify that the default response for a successful PATCH would
>> be 204, not 208.
>>
> 
> I'm assuming you meant the default preference for a successful PATCH.
> There would be no default response.

Yep.

> ...

Best regards, Julian

Received on Saturday, 4 August 2007 18:55:11 UTC