RE: HTTP Endpoints and Resources

Hello Stuart,  

> -----Original Message-----
> From: Williams, Stuart (HP Labs, Bristol) [mailto:skw@hp.com] 
> Sent: 28 September 2007 10:41
> To: Rhys Lewis; Pat Hayes; Booth, David (HP Software - Boston)
> Cc: Technical Architecture Group WG
> Subject: RE: HTTP Endpoints and Resources
> 
> Hello Rhys,
> 
> I have a question for you: 
> 
> 	These things in the 'network' that respond with 3xx and 
> 4xx responses... are you wanting to assign them URIs as well 
> - perhaps so that you an refer to them? 
> 
> I'm hoping the answer is no!

Good question. I was wondering when you were going to ask me that :)

Ok. I take a deep breath, pick up the shovel and step into the hole while
trying to stay clear of the bear trap!

To answer this, I think I need to tease it apart a little. I'm assuming
that we are talking here about the bits of Web machinery that allow an
http:resource to behave in the ways defined in RFC 2616.

So firstly, since these bits of machinery are internal to HTTP, it seems
wholly reasonable that it might not be possible to access them via HTTP
itself. I wouldn't be upset if that were the case. It would mean that I
couldn't mint an HTTP URI that allowed me to access the machinery.
However, I might be able to create one in a different scheme if I really
wanted to do something like that.

As for denoting them, I don't think you'd object to me creating an
ontology of HTTP endpoints or other bits of machinery as long as any URIs
I used were not misleading. I can envisage defining non-information
resources for the classes of endpoints and even relating specific
instances of those classes to the HTTP URIs for which they provide
responses. It seems to me that would be unambiguous as long as the
ontology spelled out the relationships correctly.

Neither of these constitutes the ability to define an HTTP URI that allows
me to access the machinery but I think that's fine. To my mind this seems
a bit like the Unix principle that everything is a file. It works just
fine until you get down to a particular level of detail, when the
underlying machinery starts having to look like something else in order to
support the principle at higher levels of abstraction. 

> 
> I'll reiterate what I said at our F2F which is something of a 
> layerist pov. I think it is a lot easier to view the web as a 
> layer that supports attempted interaction between (anonymous) 
> clients and resources (or things)[*]. A web client interacts 
> (directly) with web infrastructure (libwww, networks, origin 
> servers, caches, proxies....) which mediates
> (possible) interactions with resources. Responses to requests 
> are provided by the web infrastructure - in some cases 
> responses contain webarch:representations obtained from 
> webarch:resources and in other cases (3xx and 4xx) they don't.
> 
> In that fashion, I think, we can avoid having to speak of the 
> particular technical components that make up infrastructure 
> of the web (and their configuration etc.) - we can merely 
> focus on of 'illusion' they create of a URI addressable space 
> of webarch:resources/things - some of which have accessible 
> webarch:representation and some of which don't and some of 
> which may be held to be in correspondence with things, real 
> or imagined, in the 'real world' (Neo).

I agree that that is one approach, and that you find it satisfactory.
Personally, I've not been worried by it either. However, we have seen that
some other people are bothered by the apparent ambiguity, and this was my
attempt to see if there was a way to satisfy them.

If by technical components you mean implementations, such as the
particular configuration of a web server or the Java or Python code that
has to be written to generate the responses, then I agree wholeheartedly.
I was, however, intrigued by the notion that there might actually be an
architectural principle here. The distinction I've been making is between
the Web infrastructure, which is all of the gubbins that is not associated
with any specifically defined http:resources, and the http:resources
themselves. 

So, I would say that I get 404s from the Web infrastructure, and that is a
special, but useful and important case. However, 2XX and 3XX can't be
delivered by the infrastructure alone. URI owners have to establish
particular http:resources to make those work. That is a distinction that I
think is, at least arguably, architectural.

> 
> I accept the technical point that Pat makes, wteo "...that 
> that which is accessed using a URI is not necessarily what it 
> is intended to denote" - however, for requests that yield a 
> 4xx or 3xx response from the web infrastructure - I have very 
> little interest in what in fact responded and have no wish to 
> speak of it. I'm more interested in the intended denotation 
> of the reference that gave rise to the request made to the 
> web - and if the web can help me find out a little more about 
> that thing ("go on... ask me another question using this URI) 
> the so much the better.
> 
> So... 
> 
> - requests are made to web infrastructure;
> - responses come from web infrastructure;
> - some response bear resource representations;
> - others suggest another request question;
> - others are dead ends.
> 
> But at this level (above the infrastructure of the web) I do 
> not think that we have to speak of or refer-to the components 
> of the infrastucture itself (though they are of course an 
> important topic wrt to the engineering of web). 
> 

Except that to describe the fragment id approach to non-information
resources you do have to be absolutely explicit about the associated
http:resource that provides the response. I think I could assert that all
I'm doing in my description of the 303 case, for example, is applying the
same level of detail. There is an associated http:resource in each case.
In the fragment id case, it responds with a 200 and a representation. In
the redirect case it responds with a 303. It seems nicely consistent to
me.

Best wishes
Rhys

> Regards
> 
> Stuart
> --
> [*] I say (anonymous) because in general web clients don't 
> have generally have URI assigned to them... and are not themselves
> (generally) web accessible. In that respect I don't think of 
> a web client as a webarch:resource... however it is clearly a 
> "thing". That's not to deny that a web client could present 
> itself as a web accessible information resource, providing 
> maybe a web accessible configuration interface [which is also 
> true of other components of web infrastructure]. It may also 
> be the case that I might want to baptise my web client with a 
> URI name so that I may speak of it in conversation or in RDF 
> or HTML (or on the side of a bus)... but I wonder how that 
> would be scoped - I have instances of a web client running 
> right now... at some stage I will stop them and latter I may 
> start (new?) ones.
> 
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
> RG12 1HN
> Registered No: 690597 England
> 
> > -----Original Message-----
> > From: www-tag-request@w3.org 
> [mailto:www-tag-request@w3.org] On Behalf 
> > Of Rhys Lewis
> > Sent: 26 September 2007 07:44
> > To: 'Pat Hayes'; Booth, David (HP Software - Boston)
> > Cc: 'Technical Architecture Group WG'
> > Subject: 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 Saturday, 29 September 2007 16:15:59 UTC