On Jul 28, 2008, at 9:49 AM, Mark Nottingham wrote:
> I saw a number of +1's to this rough plan, and only Brian offering
> another path, which didn't seem to get much support.
>
> Let's try doing this (i.e., getting rid of variant -- remembering
> that there's a separate issue for 'requested variant' -- and change
> the definition of representation to be the same as that of entity,
> giving editors discretion to adjust instances of each as
> appropriate). We can revisit if necessary.
(I'm sorry I'm coming late to this conversation and perhaps you have
discussed the following, but...)
Yes, I could never understand the difference between 'variant' and
'representation'.
But I don't think making 'entity' and 'representation' synonyms makes
much sense. There are a couple of reasons.
First, if they are synonyms, there is no reason to use both.
Second, W3C (e.g. its web architecture recommendation, but the usage
has spread) reserves 'representation' to mean specifically an entity
in a 200 response. Thus an entity in a 404 response, or in a PUT or
POST request, would not be called a representation, but other entities
wouldn't. There is no reason to redefine 'representation'
unnecessarily introducing confusion with other specifications.
Webarch goes further and says that a 'representation' is 'of' the
resource, meaning that there is a special relationship between the
entity and the resource -- it carries the information associated with
the resource's current state (in the REST sense), or something like
that (a different story for services). This relationship doesn't hold
for requests or non-200 responses. This sort of makes sense because in
the English language a representation always represents something (is
a representation of something). I'm not saying there is a reason for
HTTPbis to make such a commitment - that could be considered
'application layer', and any theory of 'representation' could be left
out of the protocol.
Fourth, the idea of 'representation' is useful because the protocol
doesn't make really sense without a little bit of (informative?)
explanation of the motivation for content negotiation. It is there
because there was an intended use case, namely translations
('representations') of a document in alternative formats and languages
to meet user-agent preferences.
Jonathan