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