First version of VOSpace 2.0 WD

[Guy Rixon]

+1 to making it a get rather than a post.

+1 to keeping the detail switch as a parameter of the get.

We should check the response of web platforms (Java, C#, PHP, etc) to  
URIs with a star at the end. It's probably fine, but it bears  
checking. (I'm thinking particularly of the wiring of servlets to  
nodes in a path in Java, where the star has a local meaning).

If foo/bar/* means all the children of foo/bar,then do we allow foo/ 
bar/ to mean the same thing? Or does that mean the container itself  
(similar to ls -d)? Or is it not allowed?

The use case I see that isn't handled by the simplest form is when the  
client wants the results to be paged so as to list very big  
directories. Note "client wants": I very much feel that the service  
shouldn't be able to impose paging. Therefore, I would allow, e.g.,

  GET foo/bar/*.fits?from=42&to=666

where from=42 means start from node number 42 and to=666 means end  
after sending node number 666. No tokens, note, since we have no way  
to receive them in REST.

This could be an optional feature on the service.

Cheers,
Guy

On 19 May 2009, at 14:49, Dave Morris wrote:

> Section 3.7 - list
>
> The current 2.0 proposal is a direct copy of the existing SOAP  
> service behavior re-factored into a REST style service. However, I  
> think several parts of the list operations are overly complex for  
> most use cases (yes - I know I proposed some of the complexities in  
> the 1.1 spec, but many of these were added to get around the  
> limitations of handling large lists in the existing DOM based SOAP  
> tools available at the time).
>
> ----
>
> Proposal : Simple GET implementation of list.
>
> If we drop a lot of the complexity, then it should be possible with  
> a simple GET request.
> If we have a container node at
>
>   vos://service/path/container
>
> and the base URL for the REST service is
>
>   http://host:port/base
>
> so a REST request for the container details would be
>
>   GET http://host:port/base/path/container
>
> In which case, a simple list operation could be requested by adding / 
> * to the end of the container URI, which would return a list of the  
> child nodes as an XML stream.
>
>   GET http://host:port/base/path/container/*
>
> If we wanted to keep the wild card match for names, then adding / 
> *.txt to the container URI would return a list of the child nodes  
> with names
> that matched the pattern.
>
>   GET http://host:port/base/path/container/*.txt
>
> If we wanted to keep the detail level, this could be added as a  
> query param, so the following request would return a minimal detail  
> list.
>
>   GET http://host:port/base/path/container/*.txt?detail=min
>
> I think this simple GET version of list will meet over 99% of our  
> use cases, be much easier to implement both client and server side,  
> have
> far fewer edge cases and much simpler error responses.
>
> If we still need the complex parts to meet some use cases, then I  
> would suggest they would be better handled by the find operation, on  
> a separate service endpoint.
>
> Does anyone have a use case that wouldn't work with this simplified  
> form ?
>
> Dave