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

<paul.downey@bt.com> writes:
> 
> My understanding is that the semantics are abstract and the values used
> dependent upon the interface publisher. An interface may be designed to 
> only use a constricted set of verbs, but those may not necessarily be 
> "PUT, GET, POST, DELETE", but could be "buy, sell", "throw, catch", 
> "push, pull", or whatever.

Are you seriously saying that the value of @webMethod could be "buy"
or "sell"? I have absolutely no idea what semantics that would imply.
 
> So the method becomes a mechanism for grouping operations. It doesn't 
> make sense to me to duplicate that important communication inside and 
> across multiple bindings.

I understand the concept of grouping operations. While that may be
useful, I don't see that as the problem we're trying to solve by
putting @webMethod on the interface operation component. 

If we're really doing grouping by using semantic free terms like
"group1" and "group2", then a similar effect could be achieved
by putting such operations in different interfaces, no?

> Of course there are bindings where the abstraction meets reality, so
> if my interface is built upon "GET, PUT, POST and DELETE" and my 
> binding supports those verbs, then the binding author may elect to 
> default the abstract verb to the application protocol verb.

Is that a random occurrence or by design? That is, did I pick the
values "GET"/"PUT" etc. because I knew what they mean in HTTP
or just by chance? What if I used "get" or "Get" .. is that the
same thing?

> I'd be of the same opinion, but i'm convinced that there is a large
> community of people building constricted interfaces as we type.
> Allowing them to describe their interfaces using WSDL has great 
> benefits for those of us wanting to use a single language to
> describe all of our Web services.

Absolutely. I don't see how we're helping them by adding this
particular feature. They can define constrained interfaces now ..
just that they have to write the constraints down in some other
language other than WSDL. As DaveO said a while ago, he believes
WS-RF to be defining a constrained set of verbs. Fair enough ..
but what that means is that any closed set of specs / services
can define a constrained set of verbs as far as that closed
set of services goes. 

I just don't understand how @webMethod helps improve that scenario,
especially given the implied semantics of the "web method" concept.

> > I would specifically appreciate your explaining the relationship
> > between @webMethod and @safe (the latter of which we already have).
> 
> My understanding - i could elect to design an interface using an
> interface method "FETCH" which i can annotate using @safe="true". 
> Alternatively i could have an operation which is actually bound to 
> HTTP "GET", but which has a side-effect. So i'd mark it with 
> safe="false". Nothing new there.

There is I believe .. if you say @safe=true, then at least
best practice would encourage you to say @webMethod="GET" right?
Saying @webMethod="POST" and @safe=true would seem to fly in
the face of REST. 

I don't believe they're independent concepts.

> > Also, in a SOAP world, how would @webMethod interact with
> > wsoap:mep (and the implied HTTP method when SOAP/HTTP is in use)?
> 
> I'm not clear on this, but AIUI, that would depend upon the binding
> of the method in the same way operation @name interacts with the MEP.

That seems reasonable .. but its further making it clear to me that
@webMethod is at least strongly HTTP-oriented, if not HTTP-specific.

Sanjiva.

Received on Monday, 12 July 2004 14:52:45 UTC