W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2004

Re: Which operation?

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 20 Apr 2004 10:37:31 -0700
Message-Id: <66F195A7-92F1-11D8-AB75-000A95BD86C0@mnot.net>
Cc: www-ws-desc@w3.org
To: Mark Baker <distobj@acm.org>

Hi Mark et al,

On Apr 20, 2004, at 9:40 AM, Mark Baker wrote:
> Hmm. "getStockQuote has the semantics of GET" is what I want too, but 
> it
> seems we mean it in different ways.  I want the operation name to be a
> label ("documentation", as Arthur says) for a particular class of GET
> invocations, while leaving it such that the client/application only
> knows that "GET" occurred.  This seems similar to Mark Nottingham's
> strawman[3], as he states;
>   The nice thing here is that unlike operation name overloading (e.g.,
>   name="getFoo"), everything is in extensions; you can still name your
>   operation 'getStatus' or just plain 'Status' if you want to.

Yes; the idea is that if your code wants to use the name, it can, but 
it can also just use the (method, input, output) tuple; or vice versa.

>>          <wsdl:operation wsdl:webMethod="GET">
>>              <wsdl:input element="schema1"/>
>>              <wsdl:output element="schema2"/>
>>          </wsdl:operation>
>> But then an application can't really identify the operation when 
>> there are more than 1, like if the GoldPayingCustomer was added.
> Yes, you'd need another service/URI for that in the RESTful case.  See
> Mark's strawman again.

Right. I was thinking that you'd have some identifier for a "virtual" 
resource that the operation is associated with, and then map that to 
URIs in the binding. The most correct way to do it would probably to 
make each resource a separate portType, but that gets unwieldy quickly, 
so a means of aggregating several related resources into a portType 
(sorry, Interface) is needed.

Slightly related (and long-winded) thoughts also at:

Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 20 April 2004 13:37:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:48 UTC