OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Why REST was Re: [xml-dev] URIs are simply names

[ Lists Home | Date Index | Thread Index ]

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
> > > 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

> > 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



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS