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

comments inline.

> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> noah_mendelsohn@us.ibm.com.bea.com
> Sent: Tuesday, June 24, 2003 1:11 PM
> To: David Orchard
> Cc: 'Ian B. Jacobs'; www-tag@w3.org; xml-dist-app@w3.org
> Subject: 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.
>

Agreed.

> 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!)
+1!!!!

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

I thought any POST request MUST be encoded in RPC representation to be RPC
representation?  From the 3rd bullet of 4.1.2, "The request envelope is
encoded as described in 4.2.1 RPC Invocation, ..."
I thought the response MUST be rpc encoded?  "The results of the retrieval
are a SOAP RPC response as described in 4.2.2 RPC Response"

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

Close, and I agree in general with that set of variations.  But doesn't this
really get down to RPC encoding ( using SOAP encoding or not) and non RPC
representation?  I mean, in all 3 cases, the response MUST be RPC encoded.
In all the cases, any request body MUST be RPC encoded.  The only case where
there isn't a request body, a safe retrieval, the parameters are in the URI.

> 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?
>

I think it is accurate and reasonable, given the clarification about rpc
response pointed out earlier.  But I don't get what's wrong with using the
word encoding.  I mean, any request that exists is rpc encoded or not, and
any response that exists is either rpc encoded or not.

Having said that, I'm ok with changing the word encoding if it gets us
closure.

Cheers,
Dave

Received on Tuesday, 24 June 2003 20:46:50 UTC