Skip to content

API interactivity

Summarizing the discussion about the goal of this year, we are aiming to add more interactive endpoints to the API that will allow users to trigger actions that can modify the state of the experiments. To accomplish this there are some issues we have to solve:

Define the scope

We need to list requirements to better structure the changes we want to make. In this particular case, we can list the actions (run experiment, update description, change status, etc) we desire to include inside the API. Then, we can make a formal endpoint definition in OpenAPI with the route, expected request, and response.

Also, this will help us to link the effort we have to do in other tasks (DDBB sync, security, communication with Autosubmit, ...)

[UPDATE] Mapped actions until now:

  • Start Experiment POST /v4/experiments/<expid>?action=run -> start
  • Stop Experiment POST /v4/experiments/<expid>?action=stop -> stop
  • Set Status to Job PATCH /v4/experiments/<expid>/jobs/<jobid>?status=<newstatus> -> setstatus
  • Create experiment POST /v4/experiments -> expid
  • Generate the experiment POST /v4/experiments/<expid>?action=generate -> create
  • Restart the experiment POST /v4/experiments/<expid>?action=restart -> recovery

Set some infrastructure cases

There are multiple scenarios in which the API will be installed like in ES, Climate DT, and EDITO. Is important that we formally define those to better understand the bounds (security, network, dependencies) we are going to have for each one.

Define the action procedures

As discussed, there are some options to process the actions we want to include inside the API:

  • Modify the artifacts (DDBB and files) directly: This option is great for actions that update the metadata but will require a better understanding of the data sources as discussed in #53 to unify definitions and responsibilities. Might be hard to ensure retro compatibility as different versions of Autosubmit might use different data sources.
  • Call the Autosubmit commands: This can be used for actions that need to execute extensive procedures through a subprocess. Also, it will not add a dependency directly to the API. This allows the possibility to run the commands even if the API and Autosubmit are in different nodes but we will need to figure out how to ensure a safe communication between them. There is some discussion about it in autosubmitreact#21.
  • Use Autosubmit as a Python package: In this case, Autosubmit can be called directly through the code and can be more easily handled. Still, it adds a hard requirement that Autosubmit should be a dependency of the API. In both, the previous and this option, retrocompatibility is delegated to Autosubmit.

@mcastril @bdepaula

Edited by Luiggi Tenorio Ku