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

Hi Mark,

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 30 May 2002 21:31
> To: Williams, Stuart
> Cc: 'Henrik Frystyk Nielsen'; noah_mendelsohn@us.ibm.com;
xml-dist-app@w3.org
> Subject: Re: [getf] Proposal for Web-friendly representation of RPC's in
SOAP
> 
> Just wanted to add my 2c.
> 
<snip/>
> 
> PUT's definition doesn't allow this wiggle room; what's in the body is
> the desired state of the resource identified by the Request-URI.
> Period.

You and I had some off list discussion a couple of months back about the
language in the definition of PUT.

RFC2616 section 9.6
   ...
   The fundamental difference between the POST and PUT requests is
   reflected in the different meaning of the Request-URI. The URI in a
   POST request identifies the resource that will handle the enclosed
   entity. That resource might be a data-accepting process, a gateway to
   some other protocol, or a separate entity that accepts annotations.
   In contrast, the URI in a PUT request identifies the entity enclosed
   with the request -- the user agent knows what URI is intended and the
   server MUST NOT attempt to apply the request to some other resource.
   If the server desires that the request be applied to a different URI,
   it MUST send a 301 (Moved Permanently) response; the user agent MAY
   then make its own decision regarding whether or not to redirect the
   request.

The URI in a PUT request "...identifies the entity enclosed with the
request". This feels a little awkward from a REST POV because the narrative
does not say simply that the entity body is a *representation* of the
(requested) state of resource referenced by the request URI, it strongly
implies, even possibly states, that the entity body *is* the resource
referenced by the request URI.

The narrative contrasting PUT and POST indicates that the resource
referenced by POST might be a data-accepting process. Whereas the narrative
for PUT identifies the entity body with the referenced resource. The
definition of PUT begins:

RFC2616 section 9.6

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

What I don't see (although it may be elsewhere) is any explicit prohibition
on there being some behaviour/processing triggerred at the origin server as
a consequence of a PUT request. RFC2616 Section 9.6 explicitly states: 
 
     HTTP/1.1 does not define how a PUT method affects the state of an
     origin server.
  
So there is no-prohibition on triggering behaviour with PUT... at best I
suppose... it's undefined (which I suspect means folks could not agree!)


> If we cared, we could do PUT with SOAP by defining a new HTTP method,
> "SOAP-PUT".  It would provide the hook.

I really don't think I want to go there :-)

> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com

Stuart

Received on Friday, 31 May 2002 11:30:52 UTC