W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2003

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

From: David Orchard <dorchard@bea.com>
Date: Mon, 23 Jun 2003 14:04:50 -0700
To: <noah_mendelsohn@us.ibm.com>
Cc: "'Ian B. Jacobs'" <ij@w3.org>, <www-tag@w3.org>, <xml-dist-app@w3.org>
Message-ID: <002601c339cb$173799d0$1806a8c0@beasys.com>

Noah,

I'm completely fine with saying "SOAP RPC" when we mean requests encoding
according to the SOAP RPC representation convention.

Where I have difficulty is in the sentence "and thus supports appropriate
use of GET and POST in for both RPC-oriented and non-RPC SOAP message
exchanges.  "

I do not believe that the term "RPC" is defined or owned by the XML Protocol
working group.  SOAP RPC certainly is.  It is certainly possible to have
"RPC" requests that are not SOAP RPC encoded.  And I believe that all SOAP
RPC encoded requests are RPC requests.  It's just that the set of "RPC"
requests is bigger than the SOAP RPC definition.

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.

Cheers,
Dave

> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> noah_mendelsohn@us.ibm.com
> Sent: Monday, May 19, 2003 11:47 AM
> 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:
>
> >> However, there is a distinction between RPC,
> >> as defined by the RPC encoding in SOAP, and
> >> RPC as defined by having methods inside a body.
>
> I'm not sure I agree with your concerns.  Certainly the term
> RPC is used
> somewhat ambiguously in the industry, but in this case each
> reference is
> to a specific section of the SOAP 1.2 specification, which is
> now at PR.
> Thus, I don't think there is much ambiguity that the proposed
> text refers
> to RPC in exactly the sense that SOAP 1.2 uses it.  Following
> those links
> one finds that SOAP RPC does not depend specfically on
> encoding in the
> body. but offers the alternative of encoding the request in a
> URI with
> GET, while still preserving the possibility of convenient bindings to
> programming language methods or procedures at either end of the link.
>
> You also say:
>
> >> There is a rough implied assertion that GET=non-rpc, POST=rpc.
>
> The specific proposed text includes:
>
> "The SOAP HTTP binding (cf. section 7 of [SOAPADJUNCTS]) has
> been modified
> accordingly, and thus supports appropriate use of GET and
> POST [in <- typo
> here, sorry]  for both RPC-oriented and non-RPC SOAP message
> exchanges. "
>
> I'm probably missing something, but I don't see how this licenses the
> get=non-rpc, post=rpc interpretation.  It certainly was my
> intent to make
> clear that both GET and POST are useable for both SOAP RPC and SOAP
> non-RPC communication.
>
> All of that said, I just drafted this as input to Ian, and I would
> encourage him to rewrite or adapt as he says fit, to make it
> all clearer
> or remove any ambiguities.  I think what's important is to
> have references
> to the pertinent parts of the SOAP PR, and to explain that SOAP does
> indeed support a choice of POST/GET for both RPC and non-RPC.
>
> Also:  I haven't followed the work of the arch. group in
> detail , but I do
> hope you are adopting terminology that is consistent with the
> SOAP PR, and
> that you make the necessary references to the SOAP spec.  I
> think it will
> be confusing if W3C adopts conflicting or different uses for
> terms like
> RPC.  Thank you.
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
>
>         "David Orchard" <dorchard@bea.com>
>         05/19/2003 05:42 AM
>
>                  To: <noah_mendelsohn@us.ibm.com>, "'Ian B. Jacobs'"
> <ij@w3.org>
>                  cc: <www-tag@w3.org>, <xml-dist-app@w3.org>
>                  Subject: RE: [whenToUseGet]  PUT/POST & GET with SOAP
>
>
> I'm uncomfortable with the suggested wording.  There is a
> rough implied
> assertion that GET=non-rpc, POST=rpc.  However, there is a distinction
> between RPC, as defined by the RPC encoding in SOAP, and RPC
> as defined by
> having methods inside a body.  This mode is sometimes called
> "smuggling",
> "tunnelling".  Thus the term RPC is unclear in this context.  The
> important
> point is that from a determination of whether a service
> exposes a generic
> vs
> specific method interface, the use of SOAP RPC encoding is
> irrelevent. RPC
> requests can easily be sent using document encoding instead
> of RPC.  SOAP
> does not define the crucial difference between RPC invokes - where the
> method is in the body - and RPC encoded invokes.
>
> The Web services architecture group has been having extensive
> discussions
> about how to charaterize and describe service that expose a generic
> interface - that is GET/PUT/DELETE in the case of HTTP -
> versus methods
> inside the body.  Some of the terms bandied about include specific vs
> generic, open vs generic, api vs generic, rpc vs generic, direct vs
> mediated, etc.  [1]
>
> I think that at this time, Ian's summary is actually more
> accurate of the
> current state of affairs.  That is, GET is supported, without RPC vs
> non-rpc
> invoke styles being referenced.
>
> Cheers,
> Dave
>
> PS. I think it's very neat to be able to post a URI to the ws-arch
> document
> to support a point of discussion on web services arch.
>
> [1] http://www.w3.org/TR/2003/WD-ws-arch-20030514/#id2617205
>
> > -----Original Message-----
> > From: xml-dist-app-request@w3.org
> > [mailto:xml-dist-app-request@w3.org]On
> > Behalf Of noah_mendelsohn@us.ibm.com
> > Sent: Friday, May 16, 2003 5:54 PM
> > To: Ian B. Jacobs
> > Cc: www-tag@w3.org; xml-dist-app@w3.org
> > Subject: Re: [whenToUseGet] PUT/POST & GET with SOAP
> >
> >
> >
> > Ian Jacobs writes:
> >
> > > > A couple of suggestions:
> > > >
> > > > * The "Ongoing work on GET in Web Services" section [2]
> > has a good
> > > > reference to the SOAP support for RPC with GET, but you
> > might also
> > want to
> > > > link [3], which describes SOAP's WebMethod feature.  As
> > you may be
> > aware,
> > > > use of any flavor of RPC is optional in SOAP.  Various
> > alternatives
> > are
> > > > possible, and a "document" style is commonly employed.
> > The WebMethod
> > > > feature, which is supported by the normative SOAP HTTP
> > binding[4],
> > allows
> > > > get to be used with any type of SOAP traffic, whether RPC
> > or not.  I
> > > > expect and hope that many non-RPC users of SOAP will
> > avail themselves
> > of
> > > > the opportunity to name resources with URIs, and to use get when
> > > > appropriate.
> > >
> > > The reference is helpful, thank you.
> > >
> > > I am going to go out on a limb and ask whether you could
> draft a few
> > > sentences to be included.
> >
> > Sure, I'll try, with the proviso that this input has no
> > official standing
> > as far as the XMLP WG is concerned:
> >
> > <original>
> >
> > 6 Ongoing work on GET in Web Services
> >
> > Since the first publication of this finding, W3C's XML
> > Protocol Working
> > Group has added a GET method to SOAP 1.2 (cf. section 4.1.2 of
> > [SOAPADJUNCTS].
> >
> > Section 3 of WSDL 1.2 Bindings [WSDL] provides a binding to
> HTTP GET,
> > which makes it possible to respect the principle of using GET
> > for safe
> > operations. However, to represent safety in a more
> > straightforward manner,
> > it should be a property of operations themselves, not just a
> > feature of
> > bindings.
> > </original>
> >
> > <suggested>
> > 6 Ongoing work on GET in Web Services
> >
> > Since the first publication of this finding, W3C's XML
> > Protocol Working
> > Group has enhanced SOAP Version 1.2 to support use of GET for safe
> > operations (cf. section 6.4 of [SOAPADJUNCTS].)  Specific
> > conventions are
> > also now suggested for use of GET in conjunction with SOAP Remote
> > Procedure Calls (cf. section 4.1.2 of [SOAPADJUNCTS].)  The
> SOAP HTTP
> > binding (cf. section 7 of [SOAPADJUNCTS]) has been modified
> > accordingly,
> > and thus supports appropriate use of GET and POST in for both
> > RPC-oriented
> > and non-RPC SOAP message exchanges.  Indeed, non-normative
> > conventions are
> > suggested which allow traditional Web servers (I.e. those not
> > specifically
> > enabled for SOAP support) to interoperate with SOAP clients
> > using GET and
> > resource representations in media type application/soap+xml
> > (cf. section
> > 7.1.3 of [SOAPADJUNCTS]).
> >
> > Section 3 of WSDL 1.2 Bindings [WSDL] provides a binding to
> HTTP GET,
> > which makes it possible to respect the principle of using GET
> > for safe
> > operations. However, to represent safety in a more
> > straightforward manner,
> > it should be a property of operations themselves, not just a
> > feature of
> > bindings.
> > </suggested>
> >
> > You may want to clean up the wording, but I think the above
> should be
> > sufficient to point you in the right direction.  If there's
> > anything else
> > I can do to help, please let me know.
> >
> > ------------------------------------------------------------------
> > Noah Mendelsohn                              Voice: 1-617-693-4036
> > IBM Corporation                                Fax: 1-617-693-8676
> > One Rogers Street
> > Cambridge, MA 02142
> > ------------------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >
> > "Ian B. Jacobs" <ij@w3.org>
> > 05/13/2003 12:15 AM
> >
> >
> >         To:     noah_mendelsohn@us.ibm.com
> >         cc:     www-tag@w3.org, xml-dist-app@w3.org
> >         Subject:        Re: [whenToUseGet]  PUT/POST & GET with SOAP
> >
> >
> > On Mon, 2003-05-12 at 22:44, noah_mendelsohn@us.ibm.com wrote:
> > > I've taken a look at the latest draft of:  "URIs,
> > Addressability, and
> > the
> > > use of HTTP GET and POST".[1]  Overall, I think it's really
> > excellent.
> >
> > Thank you, Noah. It's really starting to represent a bunch of
> > input from
> > the community!
> >
> > > A couple of suggestions:
> > >
> > > * The "Ongoing work on GET in Web Services" section [2] has a good
> > > reference to the SOAP support for RPC with GET, but you
> > might also want
> > to
> > > link [3], which describes SOAP's WebMethod feature.  As you may be
> > aware,
> > > use of any flavor of RPC is optional in SOAP.  Various
> > alternatives are
> > > possible, and a "document" style is commonly employed.  The
> > WebMethod
> > > feature, which is supported by the normative SOAP HTTP binding[4],
> > allows
> > > get to be used with any type of SOAP traffic, whether RPC
> > or not.  I
> > > expect and hope that many non-RPC users of SOAP will avail
> > themselves of
> >
> > > the opportunity to name resources with URIs, and to use get when
> > > appropriate.
> >
> > The reference is helpful, thank you.
> >
> > I am going to go out on a limb and ask whether you could draft a few
> > sentences to be included.
> >
> > > * At several points the draft recommends using POST, but
> never PUT,
> > > implying that perhaps use of PUT is always inappropriate.  As I
> > suggested
> > > in [4], there may be an opportunity to do some detailed and
> > valuable
> > > clarification on the PUT/POST distinction.  At the very
> > least, it would
> > > seem appropriate to indicate that PUT or POST should be used as
> > > appropriate, perhaps just referring the reader back to
> RFC 2396 for
> > > details?
> >
> > Yes, that seems appropriate to avoid a misunderstanding;
> this finding
> > is limited in scope to discussion of GET and POST (and HEAD
> a little).
> >
> > I am following the discussion of PUT to monitor whether there is
> > an architectural issue that needs discusion in the mime type
> > finding, in a separate finding, or simply in the architecture
> > document.
> > I've not yet understood what the architectural issue is, or whether
> > RFC 2616 requires clarification for the scenario at the beginning
> > of the thread: what to do when no header sent by the client to the
> > server.
> >
> > > Thank you.  BTW:  these are my personal comments, not sent
> > on behalf of
> > > the protocols WG.  Again, I think this is overall a terrific job!
> >
> > Thank you,
> >
> >  _ Ian
> >
> > >
> > > Noah
> > >
> > >
> > > [1] http://www.w3.org/2001/tag/doc/whenToUseGet.html
> > > [2] http://www.w3.org/2001/tag/doc/whenToUseGet.html#webservices
> > > [3]
> http://www.w3.org/TR/2003/PR-soap12-part2-20030507/#WebMethodFeature
> > [4] http://lists.w3.org/Archives/Public/www-tag/2003May/0041.html
> >
> > ------------------------------------------------------------------
> > Noah Mendelsohn                              Voice: 1-617-693-4036
> > IBM Corporation                                Fax: 1-617-693-8676
> > One Rogers Street
> > Cambridge, MA 02142
> > ------------------------------------------------------------------
> --
> Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
> Tel:                     +1 718 260-9447
>
>
>
>
>
>
>
Received on Monday, 23 June 2003 17:05:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:14 GMT