Hyperlinks depend on GET (was: Re: REST and the Web)

Paul Prescod writes:

>> Without GET you don't have hyperlinking.

Paul: I agree with much of what you have written over the past few days, 
but not with this, and I think it's an important point.  Maybe it would be 
closer to the mark to say: "Without GET you don't have hyperlinking for 
browsing", but even that is arguably a bit of an oversimplification. 
Before I proceed:  this is not a critique of REST.  It is merely a 
discussion of your suggestion that hyperlinking depends on GET.

In general, I see hyperlinking as the generalized ability to refer in a 
uniform manner, in a broad range of contexts, to a large and perhaps 
diverse set of resources.  The existence and widespread deployment of URI 
architecture gives us this.  Indeed, I claim that one wants to hyperlink 
resources for which GET is not the obvious default operation.  Further, I 
claim that Metcalf's law suggests that mixing all of these sorts of links 
in one system is much more powerful than a system in which hyperlinking is 
dependent in all cases on GET.

What I think you mean by hyperlinking is the ability to reference a link, 
and without any special information on a per-link basis, have something 
useful happen.  I don't need a separate contract for each link in a 
browser page: the browser will do a GET for (a representation of) any HTTP 
or HTTPS resource that I select. 

I think we are underrating the role of the browser in that scenario if we 
assert that hyperlinking is intimately dependent on GET.  It's the browser 
that decides to do a GET.  Another application might know to DELETE every 
resource that's selected.   Another example:  let's say we have an NFS: 
URI scheme, a means of linking to NFS mountable volumes.  Cool idea.  When 
I click on such a link, do I want to GET the entire volume?  Probably not, 
but mounting it would be great.  And the fact that I could imagine putting 
such an NFS link on a web page is the essence of hyperlinking IMO.  Same 
with mailto: links;  they generally send rather than GET mail when 
selected.  Metcalf's law:  the power of my system grows when I can mix all 
of these as needed.  That's why I don't want to limit the Web to 
retrievable documents.

Who knows to do the NFS mount or mail send rather than the GET?  If we're 
browsing, it's either the browser or supporting software acting on its 
behalf (probably by looking at the URI scheme...though that's always made 
me a bit nervous vis a vis opacity of URIs).  Or maybe we're not in a 
browser at all.  Maybe we're in a special purpose volume "explorer" and we 
know from context that we try an NFS mount on any link that's selected.

My point is that hyperlinking is not tied to particular operations such as 
GET.  It's almost always the consuming application that knows what 
operation to apply to a link, maybe by looking at the URI scheme, or maybe 
from other context.

Yes, sticking to REST in the many situations to which it applies gives us 
some truly powerful interoperability scenarios.  That is among the reasons 
that REST is interesting and important.   I think the notion of 
hyperlinking in a near-universal web is mostly orthogonal to the suite of 
operations that we deploy on those resources;  to the extent we can also 
make those operations near-universal, we do significantly increase the 
ability to mix-n-match resources with applications.  So, REST is 
important, but hyperlinking doesn't in any other sense depend on GET, IMO 
anyway.  Many thanks.

P.S. I will be out of touch for 3 days or so.  I'm sure the tag would 
appreciate that we not start an extended discussion of this in any case. 
Should anyone reply, please take no offense if I don't see your note until 
middle of next week. 

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 29 March 2002 22:56:44 UTC