Re: PATCH Draft

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