UWS as a REST protocol

[Matthew Graham]

Hi,

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. Guy's REST interface for UWS is exactly the sort of thing 
we need to achieve interoperability.
> 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.
Which is why I sent the clarifying email attempting to make the point 
that we are not talking about HTTP GET + RPC, e.g. a SIAP call, but 
*web* service calls - replacing SOAP.

>> 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?
No, if the verb used is HTTP PUT then what should be returned is the 
updated representation; HTTP GET, of course, is just a retrieve which is 
why the URL should not contain verbs in the first place that could lead 
to a potential alteration of the resource.

I agree totally that exposing regions of the sky through a RESTful 
interface is not useful - unless you use something like HTM as the 
address - but again we are not talking about a REST interface on 
something like SIAP or Cone Search but on services that are dealing with 
processing jobs and data files where the resource granularity is 
manageable via REST.

>> 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.
Exactly and we are going to have to reiterate and reemphasize a lot to 
colleagues precisely what this discussion is about: REST instead of SOAP 
for *web* services and not SIAP or similar services.
> 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.
I'll have a look at that.

    Cheers,

    Matthew