W3C home > Mailing lists > Public > public-awwsw@w3.org > March 2011

Re: Roy's definition of a REST resource as a "Curried" form of ftrr:IR

From: Nathan <nathan@webr3.org>
Date: Fri, 04 Mar 2011 21:13:37 +0000
Message-ID: <4D715601.4040803@webr3.org>
To: David Booth <david@dbooth.org>
CC: AWWSW TF <public-awwsw@w3.org>
David Booth wrote:
> Nathan,
> Have you looked at the definition of IR that I proposed a while back?
> http://lists.w3.org/Archives/Public/public-awwsw/2008Apr/0046.html
> It is logically equivalent to Roy's definition of a REST resource, but
> it pulls the Request parameter out earlier.  Roy's notion of a REST
> resource, roy:RR, is basically a "Curried" form of ftrr:IR
> http://en.wikipedia.org/wiki/Currying :
>   for any Time t and Request req, ftrr:IR(t, req) = roy:RR(t)(req).

yes, there are several ways of reducing down to the same thing, essentially:

   <u> is associated with a thing T by agents via the naming process
   <u> is associated with a set of representations SR over time by the 
dereferencing process

the dereferencing process is a function which associates a 
representation with <u> via a request/response pair of messages

it can be modelled in a tonne of ways behind the interface, but you 
can't see that.

I define IR as being when T == SR, when agents use T to refer to the set 
of representations over time, the "web page" case. (200 OK)

and when T != SR then httpRange-14 says <u> refers to T, and SR has it's 
own URI (which you 303 See Other to).

but this ignores the fact that there is the ambiguous case where T != SR 
and <u> is used by agents to refer to either T or SR, or sometimes both!

> If one wishes to nitpick, Roy does not explicitly say that the second
> step of selecting a representation (via content negotiation) is
> functional, but I think it is implied:
> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1
> [[
> More precisely, a resource R is a temporally varying membership function
> MR(t), which for time t maps to a set of entities, or values, which are
> equivalent. The values in the set may be resource representations and/or
> resource identifiers. [ . . . ]
> This abstract definition of a resource . . . allows late binding of the
> reference to a representation, enabling content negotiation to take
> place based on characteristics of the request.
> ]]

yes, it's not the request OR the response, it the pair of 
request->response resulting in success that associates a representation 
with a URI, the dereferencing process.

Conneg etc is completely orthogonal, the only thing that has any effect 
on is the "resource has a state which is reflected by the 
representation" theory, but that's a pointless issue, because it's 
theory, nothing more, you can't see behind the interface.

> Furthermore, the discussion of content negotiation in section 12.1 of
> RFC 2616 also implies (but does not explicitly say) that it is
> functional:
> http://www.ietf.org/rfc/rfc2616.txt 
> [[
>    Selection [of the best representation for a response] is based on
>    the available representations of
>    the response (the dimensions over which it can vary; e.g. language,
>    content-coding, etc.) and the contents of particular header fields in
>    the request message or on other information pertaining to the request
>    (such as the network address of the client).
> ]]

as above.

> I've also left out some details about "Agent-driven content negotiation"
> and the 300 (Multiple Choices) response code, because they don't have a
> material impact on this, but again if one wishes to nitpick, they would
> have to be accounted.

resource maps to a set of values over time, resources in set are 
"resource representations" and/or "resource identifiers" - agent driven 
conneg is just mapping to a set of "resource identifiers" (URIs) which 
map to resources themselves, of which the "resource representations" are 
"resource representations" of both "resources" - it all works out fine. 
no issue.

Received on Friday, 4 March 2011 21:14:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:09 UTC