Skip to end of metadata
Go to start of metadata

Present: Aleix, Piotr, Raul, Stian (part), Graham

Summary

Piotr

What I have done: I've worked on ROSR 6 API: http://www.wf4ever-project.org/wiki/display/docs/RO+SRS+interface+6+-+discussion

Blockers:

  1. I don't have a clear vision of handling external resources. How should they be represented in the API and what format should they have?
  2. I don't have a clear vision of annotations as API resources but I haven't had much time to think about it yet.
  3. I have yet to learn what are link relations in context of this API

Plans:
learn about the link relations, look for other projects/APIs that distinguish internal and external resources

aleixgarrido

Yesterday:
worked on the API documentation. Now I've got a first draft of the API with a bit of information on each point of the template (except for link relations) ready for be reviewd.

Today:
Not sure on where to focus. Look for more information about security or cache in rest services, work on an example client, add rdf to the service, uri template expansion, etc.

Blockers:
None, but would like to see the APIs of the others to see if there's something I'm missing. And also got a bit confussed yesterday about the technical-philosophical discussion: Am I really doing REST??

Stability Evaluation API:http://www.wf4ever-project.org/wiki/display/docs/Stability+Evaluation+API

Raul Palma

Yesterday and today i am working on roevo

Stian

Yesterday:
Workflow executor (showcase 0). Using pretty much same API as the Transformation Service.

Today:
The same. No time for the Transformation service doc today

Blockers:
None, but an idea.

I've been thinking about the job API of the Transformation Service (http://www.wf4ever-project.org/wiki/display/docs/Wf-RO+transformation+service ) and my new Workflow Runner - I would want to have a common pattern of POST --> PUT so that the job does not actually start before you PUT the status on that particular job. POST is not idempotent - so if a POST request to make a job fails, the client would not know if the job is running or not.

However, if the actual job does not start before you PUT something later, you can just PUT the "run" status several times on failure (as PUT is idempotent).

However I am uncertain if I should do this as POST with an empty-ish body, which mints and returns a UUID-based URI, which can then be PUT to, or a POST with the inital data, which then is modified with PUT to make it running, or finally a separate status resource which is PUT to make it running.

(More discussion of this later - see below)

gklyne

Yesterday:

Today:

  • API review?
  • Help Kristina with RO manager install

Blockers:

  • API to review
  • anyone to review mine?
  • early finish today

Rafael González-Cabero

Yesterday:

  • Read about what is a REST interface, update accordingly the recommender service interface

Today:

  • Update the API documentation to reflect those changes and to be described using the proposed template

(Rafa has since had to attend to other matters, and will probably not be able to participate further in the sprint this week.)

Discussion

There was some general uncertainty about what is REST, and about link relations. No time to discuss in stand-up, but need to pick up ASAP, and as we do early draft API reviews.
See also: http://www.wf4ever-project.org/wiki/download/attachments/3506665/REST-APIs.pdf
(maybe I should update with note about link relations?)

Confirmed 2-week sprint duration

Stand-up chat log

And an on-time submission from rafa:

Subsequent discussion of REST and Workflow Run API

  • No labels