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

>>2) When you say that one should use PUT for creating a resource, we
>>should make it clear that this doesn't involve a SOAP message as such.
>>The semantics of PUT is that the entity-body in the request represents
>>the state of the resource to be created. If the operation succeeds and
I
>>perform a GET I get the resource that I just PUT. The PUT request
>>doesn't "execute" the SOAP message. The reason I said "as such" is
that
>>it is of course perfectly valid to PUT a SOAP message and subsequently
>>do a GET on it.
>
>If this "doesn't involve a SOAP message as such." what has it 
>got to do with SOAP?

This is exactly my point - I tried to call this out explicitly in bullet
5)

  5) In many ways, I think the proposed text conveys the difference
  between HTTP and RPC rather than SOAP. As such it seems more to be a
  description of how to use HTTP vs. RPC than a description of how to
use
  SOAP. Maybe having it in a section called "RPC and the Web" or some
  such?

The first point is that HTTP PUT has been defined with semantics that
defines the role of the entity-body in a request and we as SOAP folks
can't change that. The particular semantics of HTTP PUT doesn't allow
for execution of the body which means that there is little SOAP
involved. However, there are other methods that do allow for extra
semantics and this is where we can add SOAP semantics.

The second point is that we have to enable SOAP to be used in
combination with MEPs that contain messages that are not SOAP. That is,
we have to enable the possibility that one can do a normal HTTP GET
(non-SOAP) and get back a SOAP message in the HTTP response. For the
specific SOAP HTTP binding we are not just using SOAP as a media type
but deploy it in places where HTTP allows us to. This doesn't mean that
SOAP isn't a protocol or anything like that - just that SOAP and HTTP
can be used only in certain combinations together.

>> 3) HTTP POST has been explicitly defined to deal with "extraneous"
>> semantics and can carry parameters such as the ones defined by a SOAP
>> message. There are only a few other methods like OPTIONS that enables
>> this. That is, it is not the case in HTTP that the entity-body always
>> can be used to carry additional parameters, it is up to the
particular
>> method.
>
>Is that:
>
>a) not all HTTP methods allow an entity-body in the HTTP 
>request message, or
>
>b) of those HTTP methods that do allow an entity-body in the 
>HTTP request,
>not all such methods allow additional parameters to be carried in that
>entity body.
>
>If b) (or a and b) what constitutes 'a parameter' in once 
>sense the whole
>entity body is a complex parameter to the HTTP method. The narrative of
>RFC2616 places some very 'fuzzy' restrictions on the sort of 
>information
>that might be conveyed in particular entity bodies. But it's 
>not clear to me
>what is meant by "additional parameters" and what HTTP method based
>restrictions apply to the particular content of an entity body.

In HTTP 1.1 it is really only OPTIONS and POST that have been defined in
a manner that allows for execution of an entity body in the request.

>> 4) As to what HTTP method one is to use, I think we should leave that
to
>> the HTTP spec as it defines the semantics of its methods. To me, the
>> absolutely most important part is that it is ok to use SOAP in
>> combination with HTTP in ways that doesn't require a SOAP message in
the
>> request AND a SOAP message in the response.
>
>Well... in that case I think we have stepped outside of the 
>"SOAP 1.2 part 1
>Messaging Framework" and we are doing HTTP with SOAP Messages 
>just another
>content format.
>
>If that's what we want to do... we should say so... but I 
>wouldn't then wish
>to call it a messaging framework.

I think the specific text that Noah proposed is intended for the HTTP
binding and the RPC convention in part 2. That is, it is not part of the
messaging framework but a specific instance of a binding and the RPC
convention.

>> 5) In many ways, I think the proposed text conveys the difference
>> between HTTP and RPC rather than SOAP. As such it seems more to be a
>> description of how to use HTTP vs. RPC than a description of how to
use
>> SOAP. Maybe having it in a section called "RPC and the Web" or some
>> such?
>>
>> 6) I agree that we should not provide a mapping of SOAP into URIs as
>> this is IMO not the point of this exercise. Rather, it is to enable
SOAP
>> usage in combination with non-SOAP messages.
>
>Oh... I thought that the point was to encourage the use of 
>URIs as the means
>of identifying resources and to provide a means of making use 
>of HTTP GET to
>do things that are known to be 'safe' within HTTP binding for the SOAP
>Messaging Framework.

We do that by enabling use of HTTP GET (or any other protocol that
supports similar semantics). It is specifically targeted the SOAP HTTP
binding, not the binding framework as such. The point is that HTTP GET
doesn't really include SOAP so we have to describe how that works.

>I believe that we primarily need to describe the behavior of 
>SOAP nodes
>interactiong with SOAP nodes. 

Well, I think the idea is that a SOAP node can interact with other
things than strict SOAP nodes like for example an HTTP client that sends
a GET request forcing a SOAP message to be generated in the response.

>I think its also important that we discuss the behaviour of a 
>SOAP node when
>interacting with something that is not a SOAP (if indeed it is 
>possible for
>a SOAP node to tell the difference). 

Yes - although I think this is what Chris has been working on - the
point of Noah's text is IMO more to describe the difference between RPC
and HTTP.

Henrik

Received on Thursday, 30 May 2002 10:58:45 UTC