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

On Aug 18, 2007, at 2:38 AM, Julian Reschke wrote:
> 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.

Generally speaking, a subset of properties should have the same etag
as the whole set of properties.  I was wondering if the body also
did resource selections, like depth=infinity.

>>> 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.

Right, but you are also trying to make the HTTP model make sense
for a method that intentionally violates the HTTP model.  It is
easier just to say that PROP* is a search method that is separate from
the HTTP model.

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

Right, that's the only thing I wanted to address in the definition,
though it would also be nice to have a meaningful way of discussing
why variants effect the response selection algorithm in general.

I wish I had just removed server-side content negotiation from HTTP
when we had the chance (all of these problems are solved by 300).

....Roy

Received on Saturday, 18 August 2007 18:19:39 UTC