Lists Home |
Date Index |
Tim Bray wrote,
> Miles Sabin wrote:
> > Tim Bray wrote,
> > > I think the whole system, both the everyday Web and the Semantic
> > > Web, has a design assumption that a URI identifies something.
> > Maybe, but is that "something" a Resource in the RFC 2396 sense?
> Absolutely, beyond any shadow of doubt. 2396 says a resource is
> anything that has identity.
I think one sign of the usefulness of the "REST is just one view among
many" attitude is that I no longer feel compelled to object to the
details of this definition. That's a win IMO, because frankly I'm bored
Now I'm just compelled to object to this definition being foisted on me.
If it works for you, fine, but get your tanks off my lawn.
> > As far as network protocols and software are concerned, abstract
> > Resources do no work at all. What matters in a retrieval context is
> > that there be a functioning server that's capable of returning a
> > response, maybe with a response entity, maybe without.
> Wrong. The vast majority of software interactions with URIs - in
> browsers and web robots - involve no network traffic; rather the URI
> is used as a string to lookup an entry in a cache or proxy or spider
> state machine or whatever. This is a direct function of the
> assumption that the resource is the abstract whatever identified by
> the URI.
I disagree. Abstract Resources aren't needed for HTTP caching. Nothing
would break if you thought of it as operating in terms of entities with
URIs telling a cache where to go to get a fresh entity when the current
one is stale.
And it's worth noting that most search engines handle "resources" which
move (ie. are no longer retrievable via an earlier URI). On the REST
orthodoxy this makes no sense at all ... so much the worse for REST,
> > So, if there were no Resources, or more than one, or different ones
> > on different occasions, what would break? Can you name one piece of
> > working software that'd stop working if Resources were to vanish in
> > a puff of existential smoke overnight?
> Well, if you talked only about URIs and representations I agree, the
> web would hold together,
That's what I'm suggesting, at least at this level of abstraction.
Actually, I'd go a little further. "Representation" is now almost as
weighed down with REST baggage as "Resource" ... so I'd rather just
talk about URIs and entities (in the MIME/RFC 2616 sense).
> but it seems to me that not thinking about what URIs identify is an
> artificial constraint; sure, you can pretend not to know what the
> letters stand for in URI, but do you really feel happier as a result?
Yes, because I'm now free of the artificial constraints imposed by REST.
I can now assign higher-level denotations to URIs which make sense for
the particular concrete case at hand, even where that conflicts with
the REST orthodoxy. I can, for example, make sense of URIs with no or
with multiple interpretations (handy for RDF and a lot else besides),
or things which move or are replaced (handy for just about every web
site in existence) without having to struggle to reconcile the way
things actually work with the way REST says they're supposed to work.