new version of REST in the VO

[schaaff at newb6.u-strasbg.fr]

Hi Guy,

Quoting Guy Rixon <gtr at ast.cam.ac.uk>:

> Hi Andre,
>
> I have a supplementary question. Given that "REST" is used to
> describe many styles, including some that Roy Fielding doesn't
> consider truly RESTful, how general are the toolkits?

Many toolkits are not dedicated to REST. With RoR you can provide 
RESTful services but not necessary (close to or non REST services ). 
Restlet framework is designed for it (with WADL support in the recent 
1.1.0 release...).

> If I select a
> random toolkit, is it likely to let me build a pre-defined service
> (e.g. UWS), or do I have to pick a toolkit to suit my design?
>
Concerning for example UWS we will probably have UWS toolkits (e.g. 
Java UWS toolkit at CDS...) for different languages and thus it will be 
transparent for the end developer.
Do you think that it will be so ?

regards

André

> Cheers,
> Guy
>
> On 6 Nov 2008, at 14:23, schaaff at newb6.u-strasbg.fr wrote:
>
>> Hi Mark,
>>
>> This list is informative, we think that it is not necessary to  
>> choose one or another framework. You are true, it is possible to  
>> produce REST services without any framework (that was not easy for  
>> soap). However it could be nice to use a framework to provide de  
>> facto (mainly true with a toolkit) RESTful services.
>>
>> regards
>>
>> André
>>
>> Quoting Mark Taylor <m.b.taylor at bristol.ac.uk>:
>>
>>> On Tue, 28 Oct 2008, schaaff at newb6.u-strasbg.fr wrote:
>>>
>>>> The last version of the draft concerning the work about "REST in  the VO"
>>>
>>> I've just got round to looking at this, and it prompts a question.
>>> This is not necessarily to be fed back into changes in the document,
>>> I just want to know the answer (in the opinions of the Note authors).
>>>
>>> Section 4 gives a list of REST oriented frameworks - my (limited?)
>>> understanding of the REST approach is that it's sufficiently simple
>>> that one can just implement, or consume, a REST service without
>>> requiring any particular software framework or library support,
>>> other than a standard HTTP client/server available within many
>>> language platforms.  Is this a reasonable view?  Or is that sort
>>> of approach to be deprecated as either being, or encouraging,
>>> bad practice?
>>>
>>> thanks
>>>
>>> Mark