UWS as a REST protocol
dave at ast.cam.ac.uk
Mon Feb 26 18:51:43 PST 2007
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
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.
Matthew Graham wrote:
> 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
More information about the grid