- From: Jacek Kopecky <jacek@systinet.com>
- Date: 05 Jun 2003 16:39:06 +0200
- To: WS-Description WG <www-ws-desc@w3.org>
- Cc: Mark Baker <distobj@acm.org>
Hi all, I've been vaguely following the discussion on issue 64 [1] and this thought occurred to me: HTTP (and other application protocols) defines an interface, something like: interface HTTP { MIMEHeaders head(URI, MIMEHeaders); MIMEMessage get(URI, MIMEHeaders); MIMEMessage post(URI, MIMEMessage); MIMEMessage put(URI, MIMEMessage); } MIMEMessage := MIMEHeaders + MIMEContent This maps to a WSDL interface with four operations and MIME stuff as parameter and return value types. Now what everybody seems to expect to do is restricting this interface and still presenting it as HTTP - in other words adding strong typing: interface StockQuoteResource restricts HTTP { MIMEHeaders head(URI, MIMEHeaders); StockQuoteMessage get(URI, MIMEHeaders); // post and put not redefined as they will not be permitted anyway } StockQuoteMessage := MIMEHeaders + XML Schema element StockQuote If that's correct, we may need to add the ability to actually redefine (and maybe hide) parent interface's methods in a new interface. That feels like building a full object-oriented IDL language. If, on the other hand, REST's uniform interface principle means we shouldn't restrict it, we won't be able to describe a StockQuoteResource in WSDL and every HTTP resource described in WSDL would implement the above-mentioned HTTP interface. Personally, I would expect to be able to have a strongly-typed description of my HTTP resources so that, while a browser would use the full HTTP interface, programs could use an interface with more semantics to it. But I can't think now of any simple way to have a strongly typed WSDL interface that still shows its relation to the HTTP application-protocol interface. Does this make any sense? 8-) Jacek Kopecky Senior Architect Systinet Corporation http://www.systinet.com/ [1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x64
Received on Thursday, 5 June 2003 11:05:53 UTC