Re: Definition of "variant" and "requested variant", was: New "200 OK" status codes, PATCH & PROPFIND

Roy T. Fielding wrote:
> On Aug 17, 2007, at 6:15 AM, Julian Reschke wrote:
>> The problems that I see here are:
>>
>> 1) for PROPFIND and friends, not only request header fields and method 
>> names, but also the request *body* select the variant -- I don't have 
>> a problem with that, but it should be spelled out.
> 
> I have lots of problems with that, though I don't think it impacts
> the definition of variant. What does PROPFIND specify in the body?

For instance, the body specifies what properties to return. Thus, as far 
as I can tell, it needs to be taken into account in this definition, 
otherwise it won't help.

>> 2) a bigger problem IMHO is that allowing this additional level of 
>> indirection creates different classes of entity tags. Example: Entity 
>> tags returned in GET/HEAD/PUT/POST/DELETE can only be used for 
>> GET/HEAD/PUT/POST/DELETE. Similarly, for PROPFIND/PROPPATCH. I'm a bit 
>> concerned about that.
> 
> It is already true in practice -- people just aren't aware of it, or
> are inserting fake etags just to comply with nonsense.  From my
> perspective, PROPFIND/PROPPATCH are incredibly bad protocols within
> a protocol (essentially, search and replace tunneled through other
> resource interfaces).  I don't need HTTP to make sense of them any
> more than I need it to make sense of POST requests.

The whole point of my proposal is to build a bridge to "proper" 
resources, that can be retrieved using GET, and manipulated using PUT/PATCH.

The discussion about the semantics of "requested variant" is needed 
independently of that, because even for PUT lots of people disagree.

Best regards, Julian

Received on Saturday, 18 August 2007 09:38:34 UTC