OpenAPI Discussion

[mike-gangl]

As we define the openAPI schema requested in #3 , i'll be referring to the file in main found here: https://github.com/unity-sds/mdps-application-catalog/blob/main/application-catalog.api-fixed.yaml for some updates.

1. There are a few things we'd like to improve upon. One, the name of the file should not include the fixed label. If we change/fix items, we rely on version control to traverse back and forth, not by changing the name of the file.
2. we've provided a set of user stories here that should be reflected in the API.
3. The register process is not asking for a bunch of metadata from the user- it should be taking in a CWL file that we parse to get most if not all of the metadata required.
4. The idea of a job has not been define, this is part of the user store mentioned above as the ingest is an async process.
5. publication
6. Versions

Number 2

Number 2 is obviously the larger issue we should discuss here.

We should focus on the following APIs you have been provided in the form of user stories:

existing API Path	New API Path	Contents
/application/register	{namespace}/ogc-application-package	POST / upload CWL file, returns a jobID and the response should be 201 (resource created), not 200.
/application/{applicationName}	/{namespace}/{applicationName}	name space is required to get details of an app package. This would show all versions available of an app package
/application/{applicationName}/	/{namespace}/{applicationName}/{version}	Similar to above, but specifying a version gives you information about a specific version of the app package and links to its artifacts
N/A	/{namespace}/{applicationName}/{version}/publish	PATCH: Publishes an app package. sets published: true This does things like prevent an overwrite of that specific version that may be done constantly during development. DELETE: unpublish the app package version (set published: False
N/A	/jobs/{jobid}	POST / upload CWL file

Number 3

For now, bare minimum metadata we should capture is as follows and only requires the POST request and the CWL file:

• Uploader (retrieved from request)
• Artifact name (cwltool:id)
• Artifact version (cwltool:softwareversion)
• Description (cwltool:doc)
• Date created (system)
• Date updated (system)

Number 4

Job should be pretty simple. JobID (uuid), times, status, and message. Message would include error information if something goes wrong during the job

Number 5

this is mentioned with the 'publish' endpoint, but we need metadata to capture if an app-package version has been published or not.

Number 6

i'm ambivalent on if we want to follow a more restufl approach: /{namespace}/{applicationName}/{version} or the docker style approach: /{namespace}/{applicationName}:{version}. I think i prefer the RESTful approach as there is a simple way of listing the versions /{namespace}/{applicationName}. I don't think this really changes the underlying model of application:applicaitonVersions [1:*]

[mike-gangl]

Here's an example CWL file we should be able to upload:

https://github.com/MAAP-Project/sardem-sarsen/blob/mlucas/nasa-ogc/workflows/process_sardem-sarsen_mlucas_nasa-ogc.cwl

This should retrieve the doc and ID fields from the cwl/workflow portion and versions from the s:softwareVersion element. In the future, we can look at capturing the s:author and s:contributor and s:keywords information as well.

[rtapella]

what is "Job" here at the /jobs/ endpoint? a deployment job? Build job? Validation job?

[rtapella]

registration job? (taking an App Pack and putting it "in" the catalog)

[rtapella]

FYI MAAP is now building a deploymentJobs endpoint in the ADES. Maybe there's a similar pattern for the app catalog side