- From: Mark Baker <distobj@acm.org>
- Date: Mon, 19 May 2003 23:24:48 -0400
- To: noah_mendelsohn@us.ibm.com
- Cc: www-ws-arch@w3.org
On Mon, May 19, 2003 at 10:10:11PM -0400, noah_mendelsohn@us.ibm.com wrote: > I'm confused. You refer to WebMethod="GET_STOCK_QUOTE", but the SOAP Web > Method feature [1] doesn't do that. It specifies a choice of two fixed > values {POST, GET}, with the implication that other HTTP methods such as > PUT or DELETE might be useable if supported by the binding. My mistake. I thought we'd allowed the Web Method feature to specify methods of any underlying application protocol, not just HTTP. But my point remains; it's nonsensical to have two methods for the same task; if you use the WebMethod feature, you remove the need for specifying a wsdl:operation. > It seems perfectly consistent to me to use this with WSDL. The WSDL can > specify a WebMethod of GET, which tells the node how to represent the > request (in the URI and using HTTP GET.) The WSDL can further indicate > that the particular method is, for example, get stock quote. But in that case, the method won't be "get stock quote", it will be GET. It may be the case that somewhere on the server, "get stock quote" is invoked, but that's hidden to the client, who only knows they're invoking GET. > It can name > the arguments as a company name (string) and a day for the quote (date > type). This can drive a convention for encoding the query in the URI. > Furthermore, it allows the semi-automatic preparation of source code that > requests and accepts a stock quote, as opposed to a weather report. You > can't do that only knowing that WebMethod=GET. True, but you can declare those same things via information returned from a GET, like a form. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis Actively seeking contract work or employment
Received on Monday, 19 May 2003 23:22:18 UTC