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

I think there are many good points in this... I have tried to summarize
my comments rather than scattering them throughout. If there is some
agreement then I think we can quite easily provide updated wording.

1) We should make a sharp distinction between the SOAP HTTP binding and
the RPC convention. One can happily live with the SOAP HTTP binding
without using RPC. I don't think this is much different from what you
write already but I think should be kept as clear as possible. 

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.

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.

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.

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.

Hope this makes sense,

Henrik

Received on Wednesday, 29 May 2002 19:11:29 UTC