Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
|||||||||
