...
- GET - Returns JSON formatted list of executions.
- Returned structure:
[
{
"execution_id": <execution_id>,
"workflow_name": <name>,
"service_template_name": <template name>,
"service_name": <service name>,
"status": <execution state>
}
{
......
}
]
/api/0.1/executions/<execution_id>
- GET - Returns JSON formatted details of specific execution ID ( positive integer)
- Returned structure:
{
"execution_id": <execution_id>,
"workflow_name": <name>,
"service_template_name": <template name>,
"service_name": <service name>,
"status": <execution state>
}
- POST - Resumes a stopped execution.
- DELETE - Cancels the specified execution.
...
- GET - Returns JSON list of all services.
- Returned structure:
[
{
"id": <service_id>,
"description": <description>,
"name": <service name>,
"service_template": <service template id>,
"created": <created date>,
"updated": <updated date>
}
{
......
}
]
/api/0.1/services/<service_id>
...
- GET - Returns JSON list of all executions for the specified service id (positive integer)
- Returned structure: see /api/0.1/executions
/api/0.1/services/<service_id>/executions/<workflow_name>
POST - Starts the execution of the specified workflow name for the specified service id (positive integer)
/api/0.1/services/<service_id>/inputs
- GET - Gets the JSON formatted inputs for the specified service id (positive integer)
- Returned structure:
[
{
"name": <input name>,
"description": <input description>,
"value": <input value>
}
{
......
}
]
- Returned structure:
/api/0.1/services/<service_id>/outputs
- GET - Gets the JSON formatted outputs for the specified service id (positive integer)
- Returned structure:
[
{
"name": <output name>,
"description": <output description>,
"value": <output value>
}
{
......
}
]
/api/0.1/services/<service_id>/workflows
- GET - Lists all defined user workflows for the specified service id (positive integer)
- Returned structure: simple JSON list with workflow names, e.g. '[ "install", "uninstall" ]'
/api/0.1/templates
- POST - Validates a TOSCA template based on the JSON formatted POST body (content type = application/json)
- POST body keys and usage:
- service_template_path, string, required, URL to template or CSAR
- service_template_filename, string, optional, default to service-template.yaml
- Example body:
- POST body keys and usage:
...
- GET - Returns JSON list of stored service templates.
- Returned structure:
[
{
"name": <service template name>,
"description": <service template description>,
"id": <service template id (positive integer)>
}
{
......
}
]
- Returned structure:
/api/0.1/templates/<template_id>
...
- GET - Returns JSON formatted list of node template in specified template id (positive integer)templates in specified template id (positive integer)
- Returned structure:
[
{
"id": <node id>,
"name": <node name>,
"description": <node description>,
"service_template_id": <service template id (positive integer)>,
"type_name": <node type name>
}
{
......
}
]
/api/0.1/templates/<template_id>/services/<service_name>
- POST
- OPTIONS
- service_name
- template_id
...
- POST - Creates a service from the specified service template
...
- id (positive integer)
- Body encoding:
{
"inputs": "input1=value1; input2=value2..."
}
- Body encoding:
/api/0.1/templates/<template_name>
- PUT - Installed a service template in ARIA storage based on PUT body and encoding.
- Body encoding based on content-type in request:
- json encoding:
{
- json encoding:
- Body encoding based on content-type in request:
"template_path": <url to stored template or CSAR>,
...
- template_name
...
"template_filename": <name of main template file (optional, default = service-template.yaml)
}
- application/zip encoding: assumes body is a binary CSAR blob. If custom service template filename needed, pass in URL request args as ?service_template_filename=name.
- text/plain: assumes the body is a single file template.