Re: Why REST was Re: URIs are simply names
On Sat, 2002-02-16 at 15:45, Jonathan Borden wrote: > Aside from voluminous discussion, I don't see the actual problems caused by > URIs. Perhaps you see a contented gossip circle where I see symptoms of serious problems. Smoke doesn't always mean fire, but billowing smoke that won't disappear often suggests fire - or at least some kind of malfunction. > No doubt there _are_ problems, particularly with the definition of URI > references (e.g. URI + fragment identifier), but with URIs themselves: what > actual problems exist? * Lack of comparison rules * Lack of consistent expectations regarding "appropriate use" * General lack of consistency among the many different URI schemes * Lack of common understandings or best practices regarding what "URI processing" even means. > Note that I don't accept widespread confusion to be a problem. I strongly > agree that any areas of confusion need to be cleared up, but regarding > problems, I mean some actual problem using HTTP etc. The problems with HTTP are problems with HTTP. The problems with URI are not necessarily the problems of the particular schemes - the sum is greater than the parts. > Clearly however there is widespread confusion and disagreement, perhaps > caused by the _process_. For example IETF RFCs may contain contradictory > statements, etc. The process is part of it - the processing is what worries me most deeply. > I do think that "REST" is a good start at clearing up some of the > misunderstandings. In my book, working code rules, and the Web, particularly > HTML + HTTP represents alot of working code. Apache has to be considered one > of the great accomplishments of the Web (at least in my book), and for this > simple reason I give Fielding et al. considerable leeway to explain the > rules of how things _should_ work. I think HTML+HTTP has done a lot of good, and that REST is an improvement on the SOAP/UDDI/WSDL pileup. However, I don't find past performance to be a guarantee of future results, nor do I find URIs to have very much to do with the success of HTML+HTTP. (In fact, I find them corrosive of the good URLs have accomplished.) > > I see little evidence that URIs - beyond URLs - have contributed much > > good to the developing universe. > > Again, Fielding has contributed to Apache, and Apache _has_ inarguably > contributed to the developing universe, at least the universe we are > concerned with here. Whatever he wants to call them: URLs, URIs. Works for > me. Fielding is a brilliant guy, fine. Taking a successful abstraction - URLs (which I believe originated with Tim Berners-Lee) and wrapping it in a whole new set of philosophical mumblings - URIs - does not make URIs successful on their own philosophical merits. URLs struck an almost unique balance between human-comprehensibility and machine usability. URIs disrupt that balance toward the machine, while relying on processing which doesn't really exist. I can describe a generic XML processor. I have no clue whatsover what a generic URI processor looks like. (A generic URL processor is much simpler.) > > And I disagree to the extent that the *identifiers* contract varies from > > the expectations already built into pretty much every piece of Web > > software regarding the *locations* contract. > > > > And resources? What? Entities at least have electronic substance. > > > > The simplest answer to why URI and not URL, is that the actual _document_ > might change (perhaps a new advert is inserted, or some errata are fixed) > yet the we don't want to assign a new URL (e.g. the current URL has been > bookmarked all over the place). The answer is that the _resource_ stays the > same (and the URI identifies the _resource_), while the _entity_ changes. > This really is quite sensible. The buildings at given addresses also change on a regular basis. The principle of location will get you to some kind of entity, however, not just a generic notion of 'somethingness'. If URIs are really about "somethingness", maybe we all need to sit back and read Heidegger for a while. I'm sure that will enhance our understanding. (I'm game, though I'll need to take up smoking again. And no, I can't stand Wittgenstein.) > Another example: you bookmark: http://example.org/MyStocks?company=INTC > > The resource represents the current stock price of Intel. > > The entity is a character string. > > The URI identifies the _resource_ not the _entity_ (e.g. the particular > document returned on a GET). If it were otherwise we would be endlessly > debating what happens when the document changes (e.g. new URL). The point is > that I use URIs in practice every day, and so do you: e.g. what does > http://www.xmlhack.com identify? A _particular_ document -- nope. The resource/entity distinction is deeply exciting to people seeking extra layers of abstraction - and I'd suggest that such people have already forgotten that locators were already a layer of abstraction, as are schemes. Layer after layer after layer - and the net result is mere confusion. http://www.xmlhack.com "identifies" something in our conversation. It is a key to retrieving a given set of bytes using the HTTP protocol from the server identified by the DNS name "www.xmlhack.com" resolved to a particular IP address at a given point in time. That's plenty abstracted for most of us, and I don't thing "blessing" http://www.xmlhack.com as an identifier rather than a location achieves anything additional - or useful. > That is the thesis (literally). REST states that we are better off working > with URIs, and directly with entities not with resources. The conclusions > include an admonition against cookies (which I hate). Looks good to me. The > recommendations seem quite sound. I like the architecture (HTTP scales > _remarkably_ well, better than I would have predicted). So what is the > problem? See above. Unnecessarily complicating layers of abstraction qualify as real problems to me. That they happen to have a cult following doesn't make it any more palatable. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format