RE: [whenToUseGet] PUT/POST & GET with SOAP

David Orchard writes
-
> I'd prefer to see wording of the ilk "and thus supports
> appropriate use of GET and POST in for both SOAP
> RPC-encoded and SOAP non-RPC-encoded message
> exchanges. "  I'd like to see the word "oriented"
> massaged to encoding a bit, to be more of the encoding
> aspect rather than the notion of orientation.

I have no problem at all with where I think you're trying to go here, 
which I take to be:  "If you mean specifically SOAP RPC, then say so: just 
saying RPC is too vague."  No problem.

I'm not quite happy with your proposed text above, for reasons which I 
believe are important in the SOAP Recommendation (gee that felt good to 
write!), but probably of marginal interest to the rest of the TAG. 
Specifically, I don't think the focus on the word "encoded" is 
appropriate.  I give my reasoning below, followed by a proposed alternate 
wording:

I think we have four possible concepts subject to confusion here:

* RPC in all the difffernt flavors that one finds it in the industry. 
We're agreed, we're not trying to talk about that, and I understand you 
thought my original text did.

* SOAP RPC Representation [1]:  this is the term in the SOAP 
Recommendation that encompasses all the flavors of RPC supported by SOAP. 
As noted below, there are several variations, some encoded and some not. I 
think the REST changes apply to all of them.

* SOAP RPC Representation [1] using SOAP Encoding [2].  This is very 
clearly described in the SOAP recommendation, and is the most common 
useage of SOAP for RPC.  On the other hand, such encoding is optional with 
SOAP RPC, and indeed it is exactly such encoding that is replaced with a 
URI representation in the case our GET recommendation is followed.  Thus 
we have also:

* The REST-sensitive useage of SOAP as described in [3].  This uses XML 
bodies, encoded or not, to POST updates, but suggests that 
resource-identifying RPC arguments should be carried in the URI.  In this 
case there is generally no body at all, encoded or otherwise.  The 
response may but need not be encoded.

* So-called RPC-Literal, which seems to be emerging from the WSDL work 
group.  My understanding is that they are taking advantage of the 
lattitude in SOAP to use [1] without [2].  The REST guidelines apply 
equally to such RPC-literal as to RPC encoded, IMO.  Indeed, there is some 
reason to believe that RPC literal is emerging as the dominant usage 
pattern for SOAP RPC, but we'll see.

So, with that background I would propose to reword your proposed text as:

<DavidOrchardProposal>
"and thus supports appropriate use of GET and POST in for both SOAP 
RPC-encoded and SOAP non-RPC-encoded message exchanges. " 
</DavidOrchardProposal>
<NoahProposedRevision>
"and thus supports appropriate use of GET and POST in conjunction with the 
SOAP RPC Representation [include reference to [1]], as well as for non-RPC 
SOAP Request/Response messages [include references to [4 & 5]]"
</NoahProposedRevision>

In other words, I think the specific focus on "encoding" is inappropriate, 
because there are other flavors of RPC in the SOAP Recommendation which 
are equally affected.  Furthermore, it is the specific focus of the REST 
changes to avoid using encoding when doing a GET, as in fact we tend to 
eliminate the SOAP request body entirely (and we're silent on whether RPC 
responses are encoded in this case).

What do you think about the proposed revision? 

Noah

[1] http://www.w3.org/TR/soap12-part2/#soapforrpc
[2] http://www.w3.org/TR/soap12-part2/#soapenc
[3] http://www.w3.org/TR/soap12-part2/#RPConWeb
[4] http://www.w3.org/TR/soap12-part2/#singlereqrespmep
[5] http://www.w3.org/TR/soap12-part2/#soapresmep

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

Received on Tuesday, 24 June 2003 16:15:59 UTC