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

Difference between generic resource and REST resource

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 10 Mar 2009 12:06:33 -0400
Message-Id: <2873C37A-CC80-4A2B-8130-16EDA16BB421@creativecommons.org>
To: AWWSW TF <public-awwsw@w3.org>
Attempting to write down what I had thought was obvious during today's  
call, but wasn't....

Forget about time, for now, for the purposes of this story.

Tim gives the Bible as an example of a generic resource. My claim is  
that while there is only one Bible, there can be many REST resources  
that "implement" it, because each selection of representations of the  
generic resource leads to a different REST resource.

A REST resource is in general a "time varying membership function".  
Since I said forget about time, we can simplify that to "membership  
function" which really just means "set" (of representations).

Each generic resource might induce a REST resource consisting of the  
set (possibly infinite) of all possible representations, whether  
"realized" or not, of the generic resource. So for the Bible, the  
corresponding REST resource would contain translations into all  
languages, including extinct languages and languages not yet invented.  
I'm not sure this is what Roy had in mind; my guess is that for him a  
REST resource is something you could actually serve. So there would be  
no REST resource corresponding to the Bible generically, since we  
can't collect all translations into one place, but only particular  
REST resources, each possessing some finite (and probably small) set  
of representations.

The point is that a generic resource doesn't know what its  
representations are, except to the extent it knows with complete  
generality. If R1 is a REST resource possessing representations A and  
B, and R2 is a REST resource possessing representations B and C, then  
there may be a generic resource G possessing representations A, B, and  
C (and others), but G, R1, and R2 are definitely three distinct  
entities - none can be identified with another.

Alternatively: a REST resource is always "specific" (to some definite  
set of representations, a subset of all those that are "possible" or  
"correct") in a way that generic resources are not.

As the definitions are all sort of squishy it might be possible to  
force them to line up; e.g. one could define a generic resource by  
fiat as one that has a particular small specified set of  
representations and no others, but I don't think that is the intent  
behind the generic resources memo.

Introducing time now: You could have a REST resource providing, today,  
two representations of the Bible, and then later add a third  
representation. This is a simple time-varying REST resource. But the  
generic resource, the Bible, is not time-varying. If you access it via  
some URI, you are simply experiencing enriched provision - it's the  
server for that URI (or something) that has changed, not the resource  
itself.

I'm not saying I like any of this; I'm just chasing the consequences  
of the two theories.

Jonathan
Received on Tuesday, 10 March 2009 16:07:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 10 March 2009 16:07:24 GMT