Re: requested resource / entity / representation / variant again..

how about...

call it a response.  That way we don't make any assumptions about 
anything nor set any limitations.  You make a request, and you get a 
response.  The response may have changed or not since last time.  The 
response may vary on Accept-* headers.  The response may be cached.  The 
response may have been generated at a time specified in a Last-Modifed 
header.  The response may be the content of a file whose location 
matched the path part of the requested URI.  Or it may not.  The server 
can choose any response it wishes without any restriction.

This is basically the reality anyway.

To distinguish between the entire response message and the part of the 
message that is deemed to be "transferred", we could add some other noun 
to refer to the content (+ attributes) or refer to the response message 
as just that - the response message.

Just an idea.

Adrien


Henrik Nordstrom wrote:
> The "resource" discussion again highlighted the fuzziness on what
> "requested resource" really means.
>
> When reading the specs again I can only agree that it's still quite
> fuzzy, but for other reasons. The way "requested resource" vs
> "representation" is currently used confuses matters a bit.
>
> Intuitively "requested resource" should refer to the resource identified
> by the Request-URI. But in fact it's not..
>
> To me it seems that quite many of the places which today say "requested
> resource" maybe should say "requested representation" (if one can say
> anything like that) to align them better with the language used for
> server driven content negotiation, or perhaps we should use the term
> "variant" consistently pretty much anywhere we say "requested resource"
> or "selected representation". But neither is good if there exists
> resources with no representations associated...
>
> If not that then the concept of "requested resource" and language used
> for describing server driven content negotiation both needs to be
> adjusted/clarified to connect them together.
>
> Some examples:
> p3 4. Content Negotiation
>
>         "content negotiation" -- the process of selecting the best
>         representation for a given response when there are multiple
>         representations available.
>
> p3 4.1 Server-driven Negotiation
>
>         ... select a representation ...
>
> etc, quite consistent use representation to identify what was selected
> and acted upon. Oddly this chapter talks very little about resources
> however..
>
> However, in other areas "requested resource" or even "variant" (wasn't
> variant supposed to be killed some time ago?) is used for referring to
> pretty much the same thing. For example
>
> p4 6.5 If-Unmodified-Since
>
>         If the requested resource has not been modified since ...
>
> p4 6.6 Last-Modified
>
>         ... the variant was last modified.
>         
>
> p2 8.2.1 200 OK
>
>         GET & HEAD ... the requested resource ...
>
>
>
> While in some other areas "requested resource" seems to refer to the
> "resource" identified by the URI, regardless of any content negotiation
> taking place.
>
> And yes, Server driven content negotiation IS confusing to terminology
> as it causes the notion of a resource to be quite twisted and in reality
> is often implemented as several independent resources sharing the same
> URI...
>
> Sorry, head a litte dizzy now trying to sort some sense out of these
> terms when content negotiation is used.. can't really say I see a light
> yet.
>
> Regards
> Henrik
>
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 21 July 2009 22:42:10 UTC