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

Joshua Allen writes:

>> If you do a PUT on a resource and then you do a GET on 
>> that same resource, the response body for the GET 
>> should be the same thing that you PUT.

I'm not so sure. 

1) The Web architecture and HTTP seem quite clear that what's returned is 
a representation of a resource, and resources can surely have many 
representations.  If I do a PUT of a GIF, then surely I can get back a BMP 
or a JPEG, especially if that MIME type is requested.

2)  What says resources are immutable  Let's say I have a Web site that 
offers to host interval counters (admittedly a contrived example, but at 
least it's simple).  I do a PUT to a brand new resource:

        http://timerssRUs/decrementingCounters/counter1

What I PUT is some message that essentially says  "Initial Value = 40 
seconds".  I could encode that in SOAP or as text or in whatever form the 
site understood.  The resource is created exactly as indicated by the 
document I PUT.   If the counters update at 1 second intervals (read their 
documentation) then a GET done with the first second will indeed retrieve 
some representation of the value 40 seconds (it could be an exact copy of 
the PUT message or it could be a GIF image of a clock!).  If instead I 
wait to seconds and try a GET, I would expect to get back a representation 
of the value 38 seconds, surely not what I provided with PUT.

So, there are at least two reasons why what comes back is not necessarily 
what you put up.  The Web is much more than a simple document management 
system;  it is a network of resources, some of which are by their nature 
active and all of which expose themselves as representations. 

More fundamentally, it seems deeply broken to say that the Web deals in 
representations when doing retrieval, but that it has some more 
fundamental notion of setting state when doing creation or update.   If 
it's representations of current state for retrieval, it should be 
representations of intended state for creation or update.  If that's so, 
then there is necessarily the possibility of processing to establish the 
true state of a resource from such a representation.  I do think the HTTP 
spec is somewhat self-contradictory on this point [1]:

        > HTTP/1.1 does not define how a PUT method affects the state of 
an origin server. 

which seems to directly contradict

        > The PUT method requests that the enclosed entity be stored under the 
        > supplied Request-URI. 

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.)

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 31 May 2002 19:35:21 UTC