RE: [getf] Proposal for Web-friendly representation of RPC's in SOAP

Hi Noah,

Lots of good questions - below I have tried to address some of them,
hope this may at least explain part of where I am coming from.

When creating a resource one has to make a choice between whether the
initial representation of the resource is taken "asis" or whether it is
interpreted. For example, if I PUT a makefile, do I expect it to be
executed or not? Similarly, if I have a resource that can represent
itself as a BMP and a JPEG and I do another PUT with a GIF, do I intend
to override one of the existing representations or create a new
representation? If it *is* going to be interpreted then who is it
interpreted by? Presumably it is interpreted by a resource, but that
resource has not yet been created.

The choice HTTP made is that the immediate state of the resource created
or updated upon doing a PUT request can at least in theory be received
by a GET (possibly not though the same URI). It is possible to PUT a
resource that is being updated dynamically when doing a GET on it
(server side include is a classic example). This was one of the things
the WebDav folks thought long and hard about [1] and their solution is
to use multiple URIs: One for which there is a deterministic
relationship between the representation provided in a GET and the
internal representation of the resource; and potentially others for
various other representations.

That is, the problem of dealing with interpreted vs. editable
representations is dealt with by providing metadata that links together
URIs. This solution is in fact similar to how many Web servers use
content negotiated resource: each identifiable representation is given
its own URI: A French representation has its own URI which is different
from its Spanish representation. Tim initially defined two HTTP methods
called LINK and UNLINK that could be used to bind resource [2] linked
from [3]. WebDAV augmented the mechanism by defining a set of
properties; both are of course diving into the area of metadata.

However, because of this choice in HTTP, a SOAP message included in a
HTTP PUT request can not be expected to be executed as a function of the
PUT although it may of course be executed in another context, for
example if somebody does a GET on it.  



>Still, representations is the only interpretation that seems 
>coherent to 
>me, and that implies the possibility of some processing to 
>establish the 
>state from the representation.  That's very consistent with the first 
>quote above, and with the examples in this note.
>What am I missing?  Many thanks.  (BTW:  these are exactly the 
>same points 
>Stuart has made, I think.)

Received on Sunday, 2 June 2002 14:55:51 UTC