W3C home > Mailing lists > Public > www-tag@w3.org > February 2011

Re: HashInURI

From: Nathan <nathan@webr3.org>
Date: Sun, 13 Feb 2011 04:14:10 +0000
Message-ID: <4D575A92.3010504@webr3.org>
To: "Eric J. Bowman" <eric@bisonsystems.net>
CC: Yves Lafon <ylafon@w3.org>, Karl Dubost <karld@opera.com>, Ashok Malhotra <ashok.malhotra@oracle.com>, "www-tag@w3.org List" <www-tag@w3.org>
Eric J. Bowman wrote:
> Nathan wrote:
>> One would hope that an HTTP client noticed that http://twitter.com/
>> and http://twitter.com/ were the same URI, and in both cases 
>> http://twitter.com/ (when dereferenced successfully) does refer to
>> the same thing, the start state of a web application / interactive
>> document described in text/html, the semantics of the "conceptual
>> mapping" are consistent.
> 
> This is the part that looks like an RPC endpoint to me.  If there were
> a redirect involved, then it could be cached.  Instead, what to fetch
> next must be calculated by a script, and that's where the problem lies
> with this style.  The desirable property most impacted, is visibility.

yes, because visibility at the data tier level, the API, isn't there, if 
it was, you wouldn't be trying to figure out how you can GET data out of 
an unGETtable uri - the API is an RPC endpoint, that's the problem, it's 
not RESTful and the representations it gives out have approx zero 
semantics, hypermedia semantics or otherwise - a client side web 
application cannot by definition be an RPC endpoint, it runs on the client..

> I would hope you extend that focus to exposing links via hypertext;
> it's this failure that generates the negativity, by breaking the
> architecture we have 

yes exactly, you're just looking in the wrong place, it's the API, the 
data tier, which doesn't have links exposed, the representations have 
approx zero semantics, the API is not RESTful.
Received on Sunday, 13 February 2011 04:15:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:30 GMT