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 with it. 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, I'd say. > > 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. Cheers, Miles
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