RE: i69: Clarify "Requested Variant"

Roy T. Fielding wrote:
> Personally, I would prefer to just rewrite the sections so 
> that they make sense without knowing anything about the 
> implementation behind the interface.  But that requires 
> serious thought and a lot less emails to read.

This should be done before trying to resolve i69. Rewriting these
sections will reduce the number of ways that "requested variant" is
used. The remaining uses of the term can then be analyzed to come up
with a definition of "selected representation" (or whatever) that works.
I believe that such a term will only be needed to describe GET, HEAD,
and 303 Not Modified. In other words, "requested variant" or "selected
representation" or whatever is truly a concept specific to GET and HEAD.

> > So I would define the "selected representation" as: "The 
> > representation selected by the server based on request 
> headers and/or 
> > other factors."
> 
> Then you would be talking about the payload within the 
> response, not the (formally known as "requested variant") 
> that is the topic of this discussion.

That is the only use of "requested variant" that makes any sense at all
when replaced by "(server-)selected representation."

"Requested variant" doesn't make any sense for the description of "201
Created" and "204 No content" because the client does not have any way
of requesting a particular variant to use for the ETag (201) or the
entity headers (204). The only option that works is to let the server
return the ETag/entity headers for *any* representation of that
resource.

"Requested variant" is nonsensical when describing
If-Modified-Since/If-Unmodified-Since for any method except GET and
HEAD. The server may reject the request with a 412 if any variant fails
to meet the preconditions, or it may process the request if any of the
variants do meet the preconditions; there are currently many servers
deployed that work each way. But, the client doesn't have any way of
telling the server that only one particular variant should be checked
against the preconditions. There is a special case for GET and HEAD, in
that a 304 Not Modified may be returned instead of whatever
representation the server would have returned in a 200 OK response, if
that representation meets the preconditions.

Content-Location does not refer to a particular variant. Instead, it
refers to a set of variants; that is, the Content-Location refers to a
resource, not a variant/representation. Otherwise, the server would not
be able to use content negotiation for any URL that is used in a
Content-Location header. Many servers DO content-negotiation at the
Content-Location URL; a lot of AtomPub implementations do, for example.

- Brian

Received on Friday, 15 February 2008 09:38:57 UTC