[
Lists Home |
Date Index |
Thread Index
]
Mark Baker wrote,
> On Sun, Jan 26, 2003 at 08:41:25AM +0000, Miles Sabin wrote:
> > I disagree. Abstract Resources aren't needed for HTTP caching.
> > Nothing would break if you thought of it as operating in terms of
> > entities with URIs telling a cache where to go to get a fresh
> > entity when the current one is stale.
>
> Try to explain the role of the HTTP Vary header, without saying
> "resource", "thing", "that which a URI identifies", or the
> equivalent.
The same way RFC 2616 does. From 12.1,
The Vary header field can be used to express the parameters the
server uses to select a representation that is subject to server-
driven negotiation. See section 13.6 for use of the Vary header field
by caches and section 14.44 for use of the Vary header field by
servers.
tho' I'd prefer to replace "representation" with "entity".
Interestingly, 14.44 doesn't mention resources at all, and barely
mentions representations, prefering instead to talking about responses.
"Resource" only appears twice in 13.6 and in both cases could
(actually, I think _should_) be replaced with "URI" without loss.
Of course, a variation implies a variation on _something_. But it
doesn't follow that that something is an abstract resource in the REST
sense. In practice Vary: is primarily used to indicate to caches that
an origin server will select one of a collection of internationalized
documents on the basis of an Accept-Language: request header. If you
want to think of such collections as abstract resources, be my guest.
I'd rather not, because collections of documents, just like individual
documents, can move or be replaced, and that's not consistent with the
REST worldview.
Cheers,
Miles
|
