UWS as a REST protocol

[Paul Harrison]

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.