UWS as a REST protocol

[Guy Rixon]

Yes, we need patterns. UWS is one such and I've outlined how we might use
REST. We needed patterns at the same level - CEC and the original concept of
UWS/UWS-PA - for use with SOAP.

I don't see a pressing need for a REST toolkit on the server when developing
in Java. The web tier of JEE pretty much does REST ("REST is the architecture
of the web" etc.). The author of a server might need to introduce a
Java-binding framework. However, in the past, we've all wanted the
data-binding bit to be separate from the SOAP bit and I suspect that we
wouldn't want it laminated to the RESTfulness. Actually, one of the nice
things I found in making my first REST prototype was NOT needing to use
frameworks other than basic servlets.

A toolkit or framework on the client side might be a real benefit.


On Sun, 4 Mar 2007, 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.
>
> 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
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523