- From: Paul Prescod <paul@prescod.net>
- Date: Sat, 20 Jul 2002 17:34:05 -0700
- To: "David W. Levine" <dwl@watson.ibm.com>, www-ws-arch@w3.org
- CC: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
"David W. Levine" wrote: > >... > > As one final example, it was pointed out that returning WSDL as a response > to an HTTP get on a > SOAP URI is undesirable because it doesn't directly map to REST. The > underlying question is > in what specific ways is this undesirable, and how can the desired effect > be achieved. David, you said a lot of things worth listening to. I'll just address this question because I think I know at least one answer. Even if you ignore REST, returning WSDL from GET is a little strange because WSDL is something you need at design time. Pointing to it at runtime is at best a little convenience, not a core feature. We should not "waste" the runtime GET on a design-time feature. It is way too valuable for actually retrieving a representation of the resource's state. Even if the resource is a "big component" as in older SOAP services, it could return its runtime state and a *pointer* to the WSDL. It is easy for the runtime representation to point to the static design time object but harder for the static WSDL to point to the current runtime state. This is especially true in a universe where many resources use the same WSDL (which is what we should be aiming for REST or not). And even where it is possible, indirecting through the static WSDL is quite an inefficient way to get to the current dynamic state. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Received on Saturday, 20 July 2002 20:35:09 UTC