W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2002

RE: "important" resources

From: David Orchard <dorchard@bea.com>
Date: Thu, 18 Jul 2002 12:03:29 -0700
To: "'Mark Baker'" <distobj@acm.org>
Cc: "'Paul Prescod'" <paul@prescod.net>, <www-ws-arch@w3.org>
Message-ID: <01be01c22e93$5c077ce0$0100007f@beasys.com>

I tend to define as "important" any resource that one would want to GET a
representation from.  If there's no need for "safe" retrieval without a
priori knowledge, then it isn't "important", where "important" means it has
it's own URI.  I realize the circularity.  To me the question is: What do I
want to GET from?

In many cases, like conversational interactions, one wants a priori
knowledge and there's no requirement for safe retrievals.

A news feed service is a wonderful example of when to use only URIs.  So's
google.  So's Amazon.  The resources that are in the system (the news item
in it's in-memory and on-disk aspects) and the representation retrieved
typically match up really well.  These feel very "hyper-textual" to me.

Application/Platform specific resources (like instances of ejb/.Net
components in stateful conversations or an MQSeries transaction) sometimes
aren't the best things to identify only with URIs.  It's not that they're
not important, it's just that GET isn't an appropriate interaction so a URI
isn't needed.  I am very sensitive to Roy's points about problems of overuse
of gateways for mapping between URIs and underlying infrastructure.


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Baker
> Sent: Wednesday, July 17, 2002 7:38 PM
> To: David Orchard
> Cc: 'Paul Prescod'; www-ws-arch@w3.org
> Subject: "important" resources
> On Wed, Jul 17, 2002 at 03:26:00PM -0700, David Orchard wrote:
> > I'm extremely familiar with the TAG finding, and you know
> that.  I was
> > ...startled... that you chose to use that quote in a
> message to me.  The
> > keyword that you don't seem to want to grasp is
> "important".  And who
> > defines important.  Also the complete circularity of the argument.
> Well, to be fair, you appear to have a higher bar when it comes to
> determining "important" than do other TAG members that have expressed
> an opinion.  Perhaps we can explore that.
> > Position: use URIs for important resources.  What are
> important resources?
> > Important resources are ones that need to be GETtable, that
> is have a URI.
> > Use URIs for important resources, and important resources are those
> > resources that have URIs.  voila, circularity and the URI
> eats it's tail.
> Sure.  So let's look at the spectrum of "important".
> I would say that pretty much all SOAP 1.1 + WSDL based Web services
> appear to have an extraordinarily high bar for their definition of
> "important".  i.e. the only thing that gets a URI is a single
> "router"/rpc dispatch end-point, such as;
> http://api.google.com/search/beta2
> http://betty.userland.com/rpc2
> And those "resources" don't even support GET.  So clearly, that's one
> extreme, where "important" is interpreted to be "too
> important to worry
> about".
> I can't think of an example where *too many* things are given
> URIs, but
> many services provide more than one.  The Amazon XML/HTTP API is one
> example, if you're not comfortable with HTML based examples (though
> I've been meaning to ask what you think of XHTML 8-).  Another would
> be Moreover's news feeds, where each topic is given its own URI, upon
> which HTTP GET returns an RSS/XML document;
> http://w.moreover.com/categories/category_list_rss.html
> So, where does your definition of "important" lie?  If you were doing
> what Moreover does, would you give each topic a URI and use GET on it?
> Or would you just have one URI for Moreover, and then address topics
> with a string within some RPC call?  Or something else perhaps?
> Enquiring minds ...
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com
Received on Thursday, 18 July 2002 15:44:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:57 UTC