Re: UWS as a REST protocol

From: John Taylor <jontayler-at-gmail.com>
Date: Thu, 8 Mar 2007 10:30:06 +0000

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
Received on 2007-03-08Z11:30:40