UWS as a REST protocol

[Dave Morris]

Hiya,

Given that we want VOSpace to handle asynchronous transfers, the details 
of the transfer returned in step (2) of your example could be details of 
a state object in the server.
Initiating a VOSpace transfer is equivalent to starting a job, the 
resulting 'transfer' is an object in the server representing the state 
of the transfer.

In VOSpace, a client can initiate a transfer from one server to another, 
which means that the client is not involved in the actual data transfer 
itself.
So the client needs some state object to query to find out if the 
transfer has been completed.
Given the URI (or URL) of the transfer state, the client could use the 
REST service to read the state of the transfer.
The client could also use the same API to change the 'status' of the 
state from 'active' to 'canceled' to cancel the transfer.

With objects that represent the state of actions, e.g. UWS jobs or 
VOSpace transfers, do we need a delete operation ?
Once a job or transfer has run to completion, the state object could 
become part of the log or history of the server activity.
In VOSpace terms, this could be represented as a 'log' directory 
containing state objects for each of the past actions.

This gives us a common way of representing server logs for actions.
As with all logging mechanisms, the objects do not need to persist for 
all time, it would be upto the server how long it keeps the record for.

Dave


Matthew Graham wrote:

> Hi,
>
> You're right about the HTTP Accept header but this is difficult to set 
> from a browser.
>
> Under the current SOAP-based interface for VOSpace, representations of 
> the resource have HTTP-based URIs (the endpoints for actual data 
> transfers) already but the actual resource itself is identified with 
> the vos-based URI and there is no problem with this. An example of 
> what the REST interface could look like is:
>
> 1. POST a XML resource description to a VOSpace endpoint to create a 
> node in the VOSpace;
> 2. POST a XML transfer description to a VOSpace endpoint to create a 
> data transfer to a particular node - identified in the XML transfer 
> description with vos URI - which returns a XML transfer description 
> containing the negotiated details of the transfer
> 3. PUT data bytes to a HTTP endpoint to insert/update a representation 
> of the resource
>
>    Cheers,
>
>    Matthew
>