Re: Issue 169: Propose http method in the operation interface to simplify http binding.

* Hugo Haas <hugo@w3.org> [2004-07-12 10:26+0200]
> * Sanjiva Weerawarana <sanjiva@watson.ibm.com> [2004-07-09 19:14+0600]
> > I still haven't seen a defined semantic of what @webMethod="GET" or
> > @webMethod="POST" means in a generic sense. Can you please provide
> > those semantics? What are the accepted values for @webMethod?
> 
> Actually, this was specified in my original proposal[1] (see 2.4.5 Web
> method characterization), which was discussed and accepted with an
> open issue on syntax, which is issue 169, during our 22 April
> teleconference[2].
> 
> > Unless such semantics can be given *in an HTTP independent manner*
> > and they can potentially be bound to other protocols, I'm most
> > definitely -1 on adding @webMethod to interface/operation.
> 
> Maybe one thing which was missing from the first paragraph was:
> 
>   The Web Method property indicates that an operation has the semantic
>   of the specified Web method.
> 
> Although the definition of the GET, POST, PUT and DELETE is indeed in
> RFC 2616, I don't see them tied to HTTP. For example, GET on
> ftp://example.com/foo also means "retrieve whatever information" is at
> this address.
> 
> One thing to clarify is that Request-URI is the endpoint location.
[..]
> > Also, in a SOAP world, how would @webMethod interact with
> > wsoap:mep (and the implied HTTP method when SOAP/HTTP is in use)?
> 
> The SOAP 1.2 HTTP binding only has support for GET with the SOAP response
> MEP and POST with the request-response MEP as explained in [3].
> 
> As a parenthesis: looking back to it, I am wondering if limiting the
> request-response MEP's Web method property to POST wasn't a mistake:
> cases where for some reason PUT and DELETE are unavailable and one
> would have to use POST instead, like Atom suggests, can arise. Maybe
> the HTTP binding should have allowed all values for the
> request-response MEP and the SOAP Web Method Feature should have
> defined a SOAP header indicating the Web method intended to be
> included in the message when the binding uses a method different from
> the one intended. Anyway, that would be an issue against SOAP 1.2.
> 
> Getting back to WSDL 2.0, my friendly amendment proposed at [4] is
> actually incomplete incomplete. In the case of the SOAP HTTP binding
> we are defining, the Web method property is restricted to GET or POST
> depending on the MEP used, which would need to be specified.

I talked to Yves Lafon about my issues regarding the SOAP 1.2 HTTP
binding and the SOAP Web Method feature and I think that I understand
it now, and that I didn't before.

The SOAP Web Method Feature is a feature for use by bindings to
declare, when setting certain options accordingly, what equivalent of
a Web method they provide. For the HTTP binding defined by SOAP 1.2,
it is defined[3] that the SOAP Response MEP provides (the equivalent
of) a GET, and that the SOAP Request-Response MEP provides (the
equivalent of) a POST.

Therefore, going back to my original proposal[1] and the syntax issue,
it was wrong to use the SOAP Web Method Feature to talk about
equivalent Web methods for messages. Also, my friendly amendment[4]
doesn't make sense either.

To answer Sanjiva's question, I agree that Paul that the relationship
between @webMethod and @wsoap:mep depends on the binding. If the
binding supports the SOAP Web Method Features, these will be hints for
how to bind operations.

In the case of the HTTP binding, because of [3], I believe that we
need to say that:
- @webMethod=="GET" should bind to SOAP Response as @wsoap:mep (if the
  URI style is in use, otherwise it wouldn't be possible);
- @webMethod=="POST" must bind to the SOAP Request-Response MEP as
  @wsoap:mep;
- @webMethod=="PUT" and @webMethod=="DELETE" must bind to the SOAP
  Request-Response MEP too;
- for other values, no recommendation is done.

Regards,

Hugo

  1. http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0031.html
  2. http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/att-0085/22-ws-desc-irc.html
  3. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-suptfeatures
  4. http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0295.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/