RE: Requesting WSDL Files

I strongly disagree that normatively specifying a convention for client-side construction of URIs is any ways not restful.

In http://groups.yahoo.com/group/rest-discuss/message/4423, Roy explicitly answered this question.

Quoth Roy:
Anyway, we are talking about resource discovery over arbitrary
data categories, and hence non-hierarchical in nature. There is
nothing wrong with telling the client how it can form URI's,
assuming that such a function doesn't change much over time.
Again, for cache reasons, I prefer methods of telling the client
to use the template

http://example.com/quotes/${exchange}/${symbol}

rather than the template

http://example.com/quotes?market=${exchange}&symbol=${symbol}

There is nothing stopping WSDL-like technology from defining
both of these mechanisms.
EndQuoth

Constructing client side links versus server side links is orthogonal to hypermedia as the engine of application state as both are hypermedia.

Cheers,
Dave


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Baker
> Sent: Tuesday, July 06, 2004 8:26 AM
> To: Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org
> Subject: Re: Requesting WSDL Files
> 
> 
> 
> Hi Roger,
> 
> On Tue, Jul 06, 2004 at 09:57:17AM -0500, Cutler, Roger 
> (RogerCutler) wrote:
> > Is there anything non-RESTFUL about
> > http://example.org/my-web-service?wsdl ?  Looks to me kind 
> of like a lot
> > of operations supported by the REST-view of the Web.
> 
> It certainly uses a uniform method (GET), which is great.  But as I
> tried to describe below, having a convention whereby one needs to
> append "?wsdl" to a Web service URI is not RESTful since it doesn't
> respect the "hypermedia as the engine of application state" 
> constraint.
> AIUI, that constraint basically requires that progression through the
> application state machine has to happen via explicit linking, whereas
> this convention doesn't do that; the client software has to have
> built-in knowledge of that convention in order to get the WSDL data.
> For the same reason, it's arguably not even self-descriptive, which is
> another of REST's constraints.
> 
> What I described below is a more RESTful solution to that problem,
> since it makes the relationship between those two resources explicit
> in the message.
> 
> Mark.
> 
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On
> > Behalf Of Mark Baker
> > Sent: Monday, July 05, 2004 9:45 AM
> > To: www-ws-arch@w3.org
> > Subject: Re: Requesting WSDL Files
> > 
> > 
> > 
> > On Mon, Jul 05, 2004 at 02:33:07PM +0100, Savas Parastatidis wrote:
> > > 
> > > > 
> > > > I just don't see how one could consider WS-RF RESTful 
> .. can you 
> > > > expand more please?
> > > > 
> > > 
> > > I agree with Sanjiva. I don't see how WS-RF can be considered as 
> > > RESTful. I would say that WS-RF builds an object-oriented or 
> > > resource-oriented view of the world using angle brackets but I 
> > > wouldn't call that REST. But then again... that's just me :-)
> > 
> > Yup.
> > 
> > FWIW, using a URI convention isn't the best way to go about 
> solving the
> > WSDL-discovery problem IMO.  A more RESTful solution (i.e. one which
> > respects REST's hypermedia-as-engine-of-application-state
> > constraint) would be to explicitly declare the relationship between
> > service and description, since those are really two 
> resources.  So one
> > could imagine doing;
> > 
> > HEAD http://example.org/my-web-service/ HTTP/1.1
> > 
> > response;
> > 
> > HTTP/1.1 200 Ok
> > Interface-Description: http://example.org/my-web-service/interface
> > 
> > which tells us that the returned URI identifies the interface
> > description.  Then this request could be used to retrieve the WSDL;
> > 
> > GET http://example.org/my-web-service/interface HTTP/1.1
> > Accept: application/wsdl+xml
> > 
> > Cheers,
> > 
> > Mark.
> > -- 
> > Mark Baker.   Ottawa, Ontario, CANADA.        
http://www.markbaker.ca
> 
>   Seeking work on large scale application/data integration projects
>   and/or the enabling infrastructure for same.
> 
> 
> 

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.

Received on Tuesday, 6 July 2004 13:23:34 UTC