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