Re: hold up

On Sat, Feb 26, 2011 at 4:26 AM, Nathan <nathan@webr3.org> wrote:
> I've just been reading huge chunks of archived messages again, and there's a
> consistent phrase coming out that's just flat out wrong.
>
>  "a representation of the resource"
>
> that's not what HTTP and the specs say, a representation is a representation
> of the current or intended state of a resource. not a representation of the
> resource.

While I agree that the first is unjustified, I'm not convinced that
the second has any support in the specs, other than fleeting mention
in AWWW.

As you all know, I think, Roy did REST in part to guide the revision
of the HTTP spec. However the spec is very carefully written to NOT
assume REST; REST at best emerges from the spec - if you take
advantage of the protocol, you will tend to do things in a REST way.

The reason for this is that the nature of the resource - whether it
has state and so on - is completely inaccessible to the client, and so
any statement about it is unfalsifiable. Therefore the nature of the
resource cannot bear on correctness of behavior under protocol. The
server can do whatever it pleases. Even requiring that there *is* a
resource is beyond the power of the specification to specify. It
assumes so but it can't say "the URI MUST identify a resource".

What little there is of REST in 2116 falls outside of any MUST.

I think Roy has written about this relationship between REST and HTTP,
but I don't have a reference handy.

Also obvious I hope is that "representation" is used in completely
different ways in 2116 and AWWW.

Anyhow, I agree completely with what you say - "representation of
resource" is sloppy thinking - but I don't think it figures into any
normative writing. It is used in AWWW. AWWW ought to use the long form
consistently, or else to explain that the short form is an
abbreviation for the long form. Or introduce new terminology entirely.

All this post hoc justification and generalization is pretty annoying,
but I guess that's how standards evolve.

Jonathan

> A resource is a stateful abstraction whose state is managed by an abstract
> protocol, the abstract protocol is realized via various machine protocols
> (such as http) which manage the state of the resource via messages and pass
> full or partial representations of the current/intended state in various
> lexical forms.
>
> Thus, an http/rest resource can *only* be something that has the property of
> having it's state (even partially) managed via a transfer protocol,
> something in the realm of the machine.
>
> the weather in london cannot be a rest resource, unless you can represent or
> manipulate it's current state via HTTP, which you can't, you can only
> represent or manipulate information about the weather in london with a
> transfer protocol.
>

Received on Saturday, 26 February 2011 15:25:38 UTC