Re: HTTP Endpoints and Resources

Hello Rhys,

Rhys Lewis wrote:
>> -----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 think that I allowed in the [*] labelled footnote that you could (if 
your really wanted to) assign these things URIs either as a means of 
reference or as a means of access (or both) - I just don't feel 
compelled to do so and infact feel that speaking of them will lead to 
more confusion rather than less. I think that I might also reject a 
position that there necessarily is an http:resource in the 303 case 
(named or not)  - I think you'll get into a whole lot of futile argument 
about whether a response comes from a webarch:resource, an 
http:resource; a web cache; an origin server; a proxy etc. Viewing all 
responses as coming from web infrastructure (which may or may not have 
interacted with the referenced webarch:resource) is surely a whole lot 
simpler a picture than imagineering loads of fine-grained web 
infrastructure components.

>> 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.
>   
I take it that that you are refering to the "...that which is accessed 
is different to that which is denoted..." meme.

I think that can be satisfied by regarding all responses as being 
provided by web infrastructure - requests are made of the web, responses 
(if any) are provided by the web. Some responses arise due to 
interaction with the resource; others do not.
> 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 remain unconvinced that we need such fine grained model.
>> 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.
No you don't... you have to be absolutely clear about the way URI's are 
handled for the purposes of access, that the fragment part is 'broken 
off', placed in the back pocket for later use, and that subject of an 
access attempt is whatever is referred to by the remainder of the URI 
(the racine as David tends to call it).
> 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.
>>     

Stuart
--

Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 1 October 2007 15:48:18 UTC