These are some notes and questions I've come up with while working on the SteamCannon API.
For example, when accessing the list of deployments for an environment, the response could be either
<deployments href='http://localhost:8080/environments/1/deployments'>
<deployment href='http://localhost:8080/environments/1/deployments/1'>
<environment href='http://localhost:8080/environments/1' rel='environment'></environment>
<!-- TODO: How to deal with versions? -->
<!-- It's possible to delete the deployment's artifact. We don't want to barf if one isn't there -->
<artifact href='http://localhost:8080/artifacts/1'></artifact>
<name>weld-jsf-permalink-1.1.0.Beta1</name>
<current_state>undeployed</current_state>
<datasource></datasource>
<actions>
<!-- TODO: should we allow deployment here? -->
</actions>
</deployment>
<deployment href='http://localhost:8080/environments/1/deployments/2'>
<environment href='http://localhost:8080/environments/1' rel='environment'></environment>
<!-- TODO: How to deal with versions? -->
<!-- It's possible to delete the deployment's artifact. We don't want to barf if one isn't there -->
<artifact href='http://localhost:8080/artifacts/1'></artifact>
<name>weld-jsf-permalink-1.1.0.Beta1</name>
<current_state>deployed</current_state>
<datasource></datasource>
<actions>
<!-- TODO: current routes assume DELETE of deployment (via HTTP verb), but we probably want POST -->
<link href='http://localhost:8080/environments/1/deployments/2' rel='undeploy' />
</actions>
</deployment>
</deployments>
Or this:
<deployments href='http://localhost:8080/environments/1/deployments'>
<deployment href='http://localhost:8080/environments/1/deployments/1'></deployment>
<deployment href='http://localhost:8080/environments/1/deployments/2'></deployment>
</deployments>
We are not currently consistent. Environments are returned as a list of links, but everything else is inlined.
I've modeled the actions available for deployments on the DeltaCloud API. All actions should be a POST. Do we just add a method=delete parameter to the undeploy action?
Can actions that are not deployed be redeployed? For example, it's possible that a deployment failed. At the moment, these appear as deployments in a listing for an environment with a current_state of undeployed. Should we even show these?
- How do we deal with artifact versions?
- Can a client create a new Artifact by posting data via the API?
- Can a client create a new ArtifactVersion by posting to the API?
- How do we expose a deploy action since it requires an environment ID?
- Can an Artifact or ArtifactVersion be deleted if there are currently running deployments?