Re: UWS as a REST protocol

From: Paul Harrison <pharriso-at-eso.org>
Date: Mon, 5 Mar 2007 09:38:01 +0100

On 04.03.2007, at 20:29, Matthew Graham wrote:

> Paul Harrison wrote:

>> On 26.02.2007, at 18:47, Guy Rixon wrote:
>>> I think REST usually wins for services that are (a) public facing
>>> and and
>>> registered in our kind of registry; (b) client-server. In this
>>> case, we've
>>> already decided that they have URIs and a calling pattern that
>>> HTTP can
>>> support. If we had some new kind of service, perhaps a genuine
>>> P2P messaging
>>> kind of thing, then we might find that SOAP-over-something-other-
>>> than-HTTP was
>>> better than REST.
>>>
>>> If there arose a righteous SOAP toolkit that genuinely made SOAP
>>> both easy and
>>> flexible, then maybe it would become better than REST in
>>> practical terms. This
>>> hasn't happened yet.
>>>
>>
>> Well there is absolutely no REST toolkit at all - the fact that
>> you can do anything you want in REST is a weakness as well as a
>> strength - horrible as it is, at least WSDL is a widely
>> implemented and understood representation of the interface to a
>> SOAP web service, and can be used to generate useable client and
>> server code stubs. -To achieve useful interoperability (without
>> needing a standard for every new service) you need patterns in the
>> REST services - e.g. the sort of thing that CEA attempts.

> There are REST toolkits: Restlet (www.restlet.org), REST-art  
> (http://rest-art.sourceforge.net), and Cognitive Web (http:// 
> cweb.sourceforge.net) are just three such frameworks for REST  
> services. Also Axis2 and XFire provide support for REST web  
> services. As for producing client and server code stubs, we all  
> know that that is the source of most problems with SOAP web  
> services but I think what you really mean here is having code- 
> binding to object representations of the XML that is being passed  
> across and something like XMLBeans will have give you that.

What I meant was that there is no 'universally accepted' interface definition language for a REST service - the closest that there seems to be is that a client is expected to parse a html form to understand the possible arguments to a service (and nothing specifying what the outputs can be) - however, I think that most of the services that we want to offer have complexity beyond what is possible to represent merely in a form (though an xform might come closer to being sufficient)- WDSL perhaps could be used for REST service interface definition http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060327/ #http-binding, but it seems that religious fervour in the REST community seems to equate WSDL with SOAP....

Of the toolkits that you mention -only the first seems to be a serious effort -roughly equivalent to the servlet api. They could be making the mistake that most of the SOAP toolkits made at the start - i.e being code-first, rather than contract-first, and the one thing that we have really learnt in trying to create web-services is that defining the interface contract first is extremely important if you want to achieve interoperability.

> Guy's REST interface for UWS is exactly the sort of thing we need > to achieve interoperability.

That I agree with - WS-Resource was a disaster for CEA - the REST interface for UWS follows the CEA pattern nicely. Received on 2007-03-05Z09:38:35