Re: section 1, intro, for review

Mark Baker writes:

>> However, whatever replaces it will look an awful 
>> lot like HTTP, because HTTP embodies so many 
>> principles that are key to REST and Web
>> architecture. 

You may or may not be correct about that.  Presuming you are, then I think 
you are arguing that the URI Identity document [1] should call out REST as 
integral to the web architecture.  To use HTTP as a placeholder for REST 
does not seem appropriate to me. 
Which raises the question, should REST be called out as fundamental in 
dealing with URI's?  The proposed URI document [1] quotes RFC 2396 [2]:

>> "Any information that can be named can be a resource." 

and then goes to some trouble to point out that non-electronic resources 
such as people are certainly included, and that one can even speculate on 
URI's for such ephemeral notions as "love".  I like that. 

I don't think I want to GET or POST my love, or even necessarily a 
representation of it.  Load/Store or Get/Put is a compromise for many 
electronic resources as well.  The operations I want to do on an incoming 
video stream may be "slow down", "cut frame rate", "switch to black & 
white" or some such (suggesting that http is indeed not the last protocol 
we'll need).  So, I see some conflict between restricting the Web to REST, 
and allowing the Web to embrace all that can be named. 

I do think that REST applies well to the many resources that are well 
modeled as memory stores.  By that I include web documents, etc.  I even 
see the value of stretching a common REST model to borderline cases. 
Still, to say that the web encompasses "everything", but that as a 
consequence everything looks like a computer memory (or maybe the I/O 
ports on a computer bus), seems much too limiting.

Speaking of which, one of my few quibbles with [1] is it's presumption 
that most resources have or are "values".  For example [3]:

"The important point to note is that in general a resource is a time 
varying mapping to a value."

Whether my love has value is an interesting question.  Seriously, this 
conflicts with the universality of the web.  The resource that is a person 
is not well modeled as being or having a value.  The resource that is a 
running computer program may or may not be best modeled that way. 
Similarly for a business activity (outstanding order) that I might wish to 
query or manipulate.  I suggest there are two ways to deal with these 
concerns:

1) Leave the REST-like notion of resources having "value" out of the URI 
document.  Stick to naming of resources, and if you like, refer to 
time-varying "state" of the resource.  We can model differences of state 
as anything that would cause two identical access to the resource to 
produce differing results.  (I do think that's different from implying 
that the state can be "Get", "Put" or "Updated (Post)"

- or -

2) Indicate that there is an interesting subset of resources that are well 
modeled as being "time varying mappings to values".  For these, one can 
indeed highlight a REST-like Load/Store Get/Put/Post foundation (though I 
would prefer not to promote HTTP specifically).

I have no strong preference between the two formulations .  Hope these 
musings are helpful.  Thanks.

[1] http://www.w3.org/2001/tag/doc/identify.html
[2] http://www.ietf.org/rfc/rfc2396.txt
[3] http://www.w3.org/2001/tag/doc/identify.html#sec-resources

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Monday, 18 March 2002 19:00:38 UTC