UWS as a REST protocol

[Paul Harrison]

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.

On 26.02.2007, at 18:42, Matthew Graham wrote:

> If we are going down this path then I want to strongly reiterate  
> (to this group and other IVOA groups) that we do it properly, i.e.  
> pure REST interfaces and not the half-baked "well, it uses HTTP GET  
> and verbs" that a lot of people mean by REST.

We need to be very careful what we are saying here - REST means  
different things to different people - see Roy's response - to many  
people (when they think as clients of the service) REST involves just  
using HTTP GET to do an RPC style invocation of a service - eg SIAP,  
so that they have a URL that they can cut and paste.I agree that the  
REST (state machine) philosophy for dealing with resources is pretty  
much what we want for job management, but I am a not sure that we  
should be modelling physical inputs to the service as resources in  
this manner.

> Reworking Roy's example: http://blabla.edu? 
> service=cutout&POS=301,22&recipe=bombayduck (which would never be a  
> *web* service endpoint) - a SOAP-based *web* service version of  
> this would send a message like:
>
> <SOAP:Envelope>
>  <SOAP:Body>
>    <cutout>
>      <POS>301,22</POS>
>      <recipe>bombayduck</recipe>
>    </cutout>
>  </SOAP:Body>
> </SOAP:Envelope>
>
> to the service endpoint of, say, http://blabla.edu/services to  
> retrieve the recipe.
>
> The REST alternative is to send an HTTP GET request to the service  
> endpoint of http://blabla.edu/cutout/301/22/bombayduck.
>

In the pure RESTful alternative what if the underlying data change  
(e.g. improved calibration) then really by the RESTful theology the  
response should still return the original data not the improved data?  
- also the problem with including physical quantities as part of the  
URL  is the quantization of  those parts of the url - in the RESTful  
world http://blabla.edu/cutout/301.00000001/22/bombayduck is a  
different 'resource', but is that really a useful way of  
conceptualizing the services?

> The distinction is that REST provides a clear separation between  
> something that is addressable as a resource - the ingredients of  
> the recipe - and operations that can be carried on it - updating -  
> whilst SOAP conflates the two in messaging (and requires extra  
> machinery to make it work).

Again in this case where the 'resource' includes the 'service  
parameters' what useful operations can you do, and if you perform  
those operations on the resource how do you affect others? The  
stateful thing here is really your invocation of a particular  
service, and whether it is ready to give you back an answer - this is  
what the UWS model is all about, not trying to conceptualize the sky  
as a resource.

Maybe what we want is a mixture.....REST for the stateful, job  
management part of services, and SOAP (or REST HTTP GET with URL  
parameters) for the initial job creation - most astronomers do simply  
want to think of the action that they want to perform in a procedural  
fashion.

Here are some interesting thoughts on the matter  http:// 
pluralsight.com/blogs/dbox/archive/2006/02/17/18869.aspx -  
particularly the conclusions.


Paul Harrison
ESO Garching
www.eso.org