UWS as a REST protocol

[John Taylor]

On 8 Mar 2007, at 05:59, Doug Tody wrote:

> On Mon, 26 Feb 2007, Matthew Graham wrote:
>
>> You're right about the HTTP Accept header but this is difficult to  
>> set from a browser.
>
> I'm about a week behind on this thread, but HTTP Accept actually only
> deals with what the client is prepared to accept at the level of the
> HTTP protocol; the client says it can accept any of these formats and
> it is up to the service to pick the best one.  The FORMAT stuff in a
> DAL access reference on the other hand, deals with what an upstream
> client requests for a data format (after having reviewed a set of
> options specified by the service and having picked one), which is
> quite a different thing.

Hi Doug,
Could you explain a little further - is your distinction that the DAL  
protocols include a mechanism for determining which formats are  
available before the data is requested?



>
> Also; some of this could be moved to the level of the HTTP protocol
> (protocol level compression is a prime example) but this is  
> inadvisable
> for functionality which we may want to map transparently onto multiple
> protocols.  HTTP Accept is an example of something which we want to
> deal with transparently at the level of the wire protocol; HTTP in
> this case.

As I understand it, REST advocates view HTTP as much greater than a  
wire protocol, for them it's an application protocol.  So, I guess  
the question is why would you invent another application protocol if  
one already exists that will do the job, is proven to be successful,  
and is widely supported.


>
> 	- Doug
>
>
>
>> John Taylor wrote:
>>> (getting in here before Norman Gray does)....I understand that it  
>>> would be more RESTful to use the http Accept header, rather than  
>>> an explicit FORMAT parameter.  If we were really hardcore we'd  
>>> also use URIs that are dereferencable using standard  
>>> protocols....so VOSpace resources would be name http://something  
>>> rather than vos://something.  Is that possible Matthew, or  
>>> wouldn't that be compatible with the VOSpace spec?
>>> John