HTTP Endpoints and Resources

Hello everyone, 

I'd like to pick at the question of HTTP endpoints a bit, as this seems to
be related to something that came up at last week's TAG F2F. I've taken
the liberty of starting a new thread.

The discussion came up because of a difference in the way the term
'resource' is defined in the terminology section of the HTTP specification
[1] and the way it's defined in the web architecture [2]. I'll use
http:resource for the former and webarch:resource for the latter in what
follows. 

With apologies to the authors of those specifications, roughly, an
http:resource is a "A network data object or service that can be
identified by a URI" and a webarch:resource is "whatever might be
identified by a URI". 

Just looking at the mechanics for a moment, if I want to create an http
URI and use it in the Web I need to have an http:resource associated with
it. If I don't have one, I'm going to get a 404 response code at best
(there are lots of others that I might get, depending on what other parts
of the Web infrastructure I've not established). Whether I want to serve
representations directly from this resource or whether I want to return a
303, in the manner of the httpRange-14 finding, I still need an
http:resource for the URI.

I think there is a real distinction here between URIs that result in 404s
and those that result in 200 and 303 (I'll ignore the other possible
responses for now). To get a response of 200 or 303 I need to have done
something more than simply deploy a server. I have to have done something
specific to allow such a response to be returned for that particular URI.
I've heard this described in various ways, including 'deploying the URI'
or 'putting it on the Web'. There are many ways to achieve this behaviour,
and often they are implementation and server specific. Nevertheless, the
distinction is that for 200 and 303 I need to do something specific for
the URI, whereas for 404 I don't. 

For an information resource, I think the webarch:resource and the
http:resource are the same thing. What is denoted is what responds, with a
200 and a representation, when poked. 

For a non-information resource, the http:resource and the webarch:resource
are distinct. What responds is not what is denoted. However, there is a
well defined relationship between the two. Where redirection is employed,
the entity that responds with the 303 is the http:resource associated with
the URI of the non-information resource. Where secondary resources are
employed, the entity that responds is the http:resource associated with
the racine of the non-information resource.

Regardless of the mechanism, in both cases, there must be an http:resource
that is specifically assocated with the URI and that provides a response
when poked.

So that's a very round about way of saying that I don't view HTTP
endpoints, as portrayed in the discussion below, as just things that
return 200. I think we're talking about http:resources here and there is a
set of response codes that such endpoints can return and which can be used
to good effect. 

I do, however, think that there is a distinction between those URIs for
which specific http:resources have been created and those for which they
have not.

And, of course, I'm only considering http URIs in all of this.

Best wishes

Rhys


[1] http://www.w3.org/Protocols/rfc2616/rfc2616.html
[2] http://www.w3.org/TR/webarch/

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Pat Hayes
> Sent: 25 September 2007 21:19
> To: Booth, David (HP Software - Boston)
> Cc: Technical Architecture Group WG
> Subject: RE: Some TAG review of "Cool URIs for the Semantic Web"
> 
> 
> >  > From: Pat Hayes
> >>  [ . . . ]
> >>  OK, fair enough. But now, lets cut out all this  gabble about 
> >> 'information resource'. As I have  always suspected, this is ALL 
> >> about HTTP codes.
> >>  If you do a GET with a URI and you get a 200  response, 
> then the URI 
> >> is understood to denote  the resource that sent you that 
> response, a  
> >> (REST-)representation of which you now have.
> >>  Otherwise, you know nothing at all about that the  URI 
> denotes: it 
> >> might denote anything.
> >
> >I agree 100%.  I think the key question to ask is: *Why* is it 
> >architecturally significant to distinguish between "information 
> >resources" and non-"information resources"?  Why doesn't the Web 
> >architecture distinguish between other interesting classes 
> of things, 
> >such as mammals and non-mammals?
> >
> >AFAICT the answer is that some things are HTTP endpoints (i.e., can 
> >return a 200 response) and some are not, and this distinction is 
> >relevant to the Web architecture because when something is an HTTP 
> >endpoint a lot more architectural rules apply, such as content 
> >negotiation, media types, etc.  AFAICT, whether something's 
> "essential 
> >characteristics can be conveyed in a message"[1] is quite irrelevant.
> 
> Yes, exactly. And if one wanted to say something that went 
> beyond mere HTML, then speak of a 'transfer protocol 
> endpoint' for xxTP. But the point still stands: endpoints are 
> one thing, denotations are another.
> 
> Pat
> 
> >
> >1. http://www.w3.org/TR/webarch/#def-information-resource
> >
> >
> >David Booth, Ph.D.
> >HP Software
> >+1 617 629 8881 office  |  dbooth@hp.com
> >http://www.hp.com/go/software
> >
> >Opinions expressed herein are those of the author and do not 
> represent
> >the official views of HP unless explicitly stated otherwise.
> >
> 
> 
> -- 
> ---------------------------------------------------------------------
> IHMC		(850)434 8903 or (650)494 3973   home
> 40 South Alcaniz St.	(850)202 4416   office
> Pensacola			(850)202 4440   fax
> FL 32502			(850)291 0667    cell
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> 
> 
>

Received on Wednesday, 26 September 2007 06:43:56 UTC