Why REST was Re: URIs are simply names
Simon St.Laurent wrote: > On Sat, 2002-02-16 at 12:01, Paul Prescod wrote: > > "Simon St.Laurent" wrote: > > > URLs are genuinely successful. The scheme: approach was a good idea. > > > However, I don't think any strong case can be made that URIs are genuine > > > contributors to the success of that information system, except to the > > > extent that they overlap with URLs - and, in many ways, damage the > > > usefulness of URLs. > > ... > > And I'm saying that I find your claims inappropriate. The problems and > discussions we have on a regular basis with URIs are not problems with > URLs. They are additional ugly problems brought on by the philosophical > freight URIs carry. Aside from voluminous discussion, I don't see the actual problems caused by URIs. 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? 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. Clearly however there is widespread confusion and disagreement, perhaps caused by the _process_. For example IETF RFCs may contain contradictory statements, etc. 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 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. > > > People SHOULD treat URLs (even HTTP) ones more like *identifiers* rather > > than *locators* in the sense that you should think of the identifier as > > being welded to the resource and not just a convenient way of finding it > > on the network. > > 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. 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. 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? Jonathan
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