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

In the same way that we can define "safe" at the interface operation level using HTTP semantics, we can define "webMethod" at the interface operation level using HTTP semantics.  We should certainly define for our 2 bindings what webMethod means at the binding level.  And any 3rd party binding should do the same.  

We could come up with our own "CRUD" definitions and then say that C=POST, R=GET, U=PUT, D=DELETE when bound to HTTP.  Then somebody else could bind CRUD to their protocol.  But I figure for the "Web" services language that using GET, etc. - which are defined and used in all of our bindings - will hit the 80/20 mark without some unnecessary and arbitrary abstraction layer.

I could live with removing "safe" as a duplicate of "webMethod" on the interface operation level.  And I'd be prepared to argue that with external groups like the TAG if there were any issues.

I don't know what "GET on mailto:foo@bar.com" means because I don't have a binding.  It could mean "get the mail for foo@bar.com".  I also don't know whether that's safe or not.  

Cheers,
Dave

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Sanjiva Weerawarana
> Sent: Monday, July 12, 2004 10:59 AM
> To: Hugo Haas
> Cc: www-ws-desc@w3.org
> Subject: Re: Issue 169: Propose http method in the operation interface
> to simplify http binding.
> 
> 
> 
> (I don't understand why but all of your messages' root MIME part also
> gets displayed in my mail reader as an attachment. Doesn't happen for
> anyone else. Weird.)
> 
> "Hugo Haas" <hugo@w3.org> writes:
> > 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].
> 
> I looked up [1] and it doesn't really give a semantic for
> what @webMethod means for an *arbitrary* operation. It just
> says that for protocols which are designed to manipulate
> resources these verbs make sense. 
> 
> If we're going to put @webMethod on /definitions/interface/operation
> then we need a very well defined semantic for what that means 
> without referring to HTTP specific things or SOAP specific things.
> Your reference doesn't provide either!
> 
> You say that we reduced it to a syntax issue .. but AFAIK we
> reduced it to a syntax issue *within the http binding*: whether
> to provide explicit syntax or use the F&P syntax. We never 
> accepted to put this thing on interface operation components
> AFAIK. Did I miss something that criticial??
> 
> > 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.
> 
> So what does GET on mailto:sanjiva@opensource.lk mean? I don't see
> how you can make such arbitrary application of the HTTP verbs 
> to any old URI and expect it to make sense .. if you explain the
> above try DELETE mailto:sanjiva@opensource.lk too!
> 
> > I think that the only relationship is:
> > 
> >   webMethod == GET => safe = true
> 
> In other words, we don't need @safe anymore .. we already say that
> @safe=true MUST means its safe and no information is given otherwise.
> Since @webMethod=GET MUST also means its safe, saying @webMethod=GET
> will achieve the same thing.
> 
> > 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.
> 
> I have no problem with you raising issues against SOAP 1.2, but IMO
> they made the right pragmatic decision in dealing with GET/POST .. the
> only two methods that I personally would open up on any production
> server :-).
> 
> Sanjiva.
> 
>

Received on Monday, 12 July 2004 17:01:37 UTC