Hello All,

I have posted a question related to this issue at yahoo REST group,
hopefully we'll have some enlightenment from REST gurus
http://tech.groups.yahoo.com/group/rest-discuss/message/13728 .

Thinking aloud, here is a proposal :

    * Introduce a Prediction resource (well, REST says if you have
      troubles how to map something to the REST style, invent a new
      resource). This is basically a Dataset, generated by applying a
      Model on another Dataset, so the representation formats are the
      same as for the Dataset resource.
    * GET on Prediction has the same behaviour as for the Dataset.
    * POST on Prediction accept as parameters Dataset URI and Model URI
      and essentially creates a new Dataset . Upon creation, the Model
      resource will be contacted , it will generate the predictions and
      return them in some representation. The representation will be
      used to create the Prediction URI. Now for this to work POST on
      Model resource should return representation of the predictions,
      not an URI.   There can be even separate implementation of the
      Prediction resource, depending on if Model is remote or a local
      resource, but this is transparent for the outside.

This decouples the locations of the original and predicted dataset and
the model.  The drawback I see is Model may be less RESTfull (e.g. not
creating URI upon POST, but I think this is acceptable for a POST
operation).

What do you think?

Best regards,
Nina

Nina Jeliazkova wrote:
> Hello Tobias, Christoph, All,
>
> We have been also discussing the issue here, but without conclusions. 
> The case when a service (e.g. descriptor calculation) just process the
> data and generates a result to be stored elsewhere is a typical RPC
> behaviour, typical for  SOAP WS and is more or less a common use case
> for OpenTox.  It is not clear for me how to map it best to the REST
> style, if possible at all.
>
> Best regards,
> Nina
>
>
> Christoph Helma wrote:
>   
>> Excerpts from Tobias Girschick's message of Wed Oct 07 16:00:26 +0200 2009:
>>   
>>     
>>> Hello All,
>>>
>>> there is another point that arose during our internal discussions on the
>>> API. Where does a service that wants to store data, e.g. calculated
>>> data, know where (or on which server) to store (POST) it? Can we
>>> introduce something like server_uri as additional parameter for the
>>> services?
>>>
>>> A possible scenario is that the user calculates features
>>> using  /algorithm/descriptorcalculator and wants to ensure that the
>>> generated features (and feature_definitions) are POSTed to a specific
>>> server, say 
>>> POST feature123 http://userserver:8080/feature 
>>> POST feature_definition345 http://userserver:8080/feature_definition
>>>
>>> This issue will/might also arise if a developer does not want to
>>> implement the whole (or most of) the API, but just a new model
>>> development or descriptor calculation service as a contribution to
>>> OpenTox.
>>>     
>>>       
>> Do you think that choosing a dataset server e.g. from a configuration
>> file is too unflexible for your algorithm service? Your proposal would
>> mean that each user can select a different dataset server - is this a
>> common use case? I personally would not offer this choice to my users,
>> but I think that every developer has the freedom to add parameters to
>> the existing API (as long as they are documented and the offical API
>> works with a reasonable default). 
>>
>> Regards,
>> Christoph
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>   
>>     
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>