Re: i69: Clarify "Requested Variant"

On Thu, Feb 14, 2008 at 10:49:53AM -0800, Roy T. Fielding wrote:
> 
> On Feb 14, 2008, at 5:25 AM, Julian Reschke wrote:
> 
> >Adrien de Croy wrote:
> >>Quick question (hopefully) - what's the difference between  
> >>"representation" in this case and "entity"?  I feel I'm missing  
> >>something.
> >>...
> >
> >OK, let's try.
> >
> >A representation:
> >
> >"An entity included with a response that is subject to content  
> >negotiation, as described in Section 12. There may exist multiple  
> >representations associated with a particular response status." --  
> ><http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.1.3>
> 
> Yikes, no thanks.
> 
> >An entity:
> >
> >"The information transferred as the payload of a request or  
> >response. An entity consists of metainformation in the form of  
> >entity-header fields and content in the form of an entity-body, as  
> >described in Section 7."
> 
> That is a representation.  I was hoping to replace entity at some  
> point for
> that reason.  The payload is always a representation of *some*  
> resource.  The
> status code tells us which resource it is, and Content-Location tells  
> us its
> most specific URI.
> 
> Getting back to Mark's proposal regarding 'requested variant'... I think
> that is headed in the right direction but will need some tweaks.
> 
>    PROPOSAL: Remove 'requested variant' from terminology and define
>    'selected representation' as (roughly): "The representation that  
> would be
>    returned by the server if the request method were GET, taking into
>    consideration selecting headers, as specified by the Vary  
> header's payload."
> 
> I would say that it is: "The representation that would be returned by  
> the
> origin server if the request method were GET and the response status  
> 200."


That inter-method-dependency is unacceptable. You say that the server 
may even select a representation based on whatever it wants, but it 
can't make it method dependend?

A POST may perfectly select the representation of the response based on 
some Accept-* headers, but the server may not even return something 
similar on GET at all. (Not to speak of any new/unknown method.)

And a GET -> "410 Gone" with a long long explanation could have a 
selected representation (in the language of the clients choice 
explaining why something is gone) as well.

Accept-* request headers express the wishes of the client on how to 
answer that request. They should not be overloaded with request 
entity attributes out of two reasons:
-use Content-* for that
-it's name (hey, it is called "Accept")

Entity response headers apply to the response entity with the miserable 
exceptions being marked with Location: on 201 responses. That means the 
Location header is already overloaded.


So I would define the "selected representation" as: "The representation 
selected by the server based on request headers and/or other factors."


Roy, do you mean that all response entities are "representations"?


> Note that Vary is one of those fields that is overspecified in 2616.
> Vary is supposed to be instructions to any downstream caches, not a
> limitation on origin server implementation.  A server is fully within  
> its
> rights to vary its representations however it likes without telling
> the downstream recipients -- it only needs to tell the client what it
> requires of any downstream cache keys (i.e., the interface requirement).



Robert

Received on Friday, 15 February 2008 01:27:52 UTC