Re: The range of the HTTP dereference function

On Wednesday 27 March 2002 07:01 pm, Miles Sabin wrote:
> To clarify, are you saying that those bare URIs are ambiguous
> (between the text and the image) until supplied with some
> disambiguator (eg. an Accept:
> header in the online case, metadata in the offline case, some other
> formal or informal convention, or the use context)?

I think the important thing to realise here is that a request is not 
simply equivalent to a GET+URI pair. Even for GET, the actual request 
is a far more complicated thing, including all the Accept headers, and 
in many cases, headers identifying the client platforms etc. This 
entire thing is the "closure" of the request.

Speaking for myself, I think there is a spectrum of cases that need to 
be considered vis-a-vis resource to representation mapping. If you 
request the time, you would expect the representation to vary, even if 
the entire request was exactly the same as an earlier one. On the 
other hand, if I ask for /foo.xml, using exactly the same request as I 
did earlier, I would be most upset to get back an image rather than 
the previously returned XML file.

You could argue that the implied contract here is outside the scope of 
the architecture, but at some point there is a *need* to represent a 
given resource with a particular set of bits, if only for reification 
so you can discuss the properties of that representation. Even in 
loosely coupled systems, sooner or later *something* has to reliably 
manage the communication protocol... and you can't do that without 
constraining types/vocabularies to fit the grammar of the protocol.

Received on Friday, 29 March 2002 23:14:41 UTC