This document explains what conventions and coding guidelines to follow when writing new API(s) for CloudStack or updating the existing ones.
When you need to introduce a new API command to the CS, you will need to create a Request Class and a Response class (or re-use existing API Response class, if you are extending CS API functionality for which API response is already defined)
CUD (create/update/delete commands):
R (read-list) commands:
Important - starting 2.x, new CUD API command can no longer extend BaseCmd class; they should come as Async command, and extend either BaseAsyncCmd, or BaseAsyncCreateCmd.
When to extend BaseAsyncCmd vs BaseAsyncCreateCmd? Use BaseAsyncCreate for the commands creating a new CS entry. For UD commands extend BaseAsyncCmd.
2. Command class that you add, should end with *Cmd, and annotated with @ApiCommand. Read more about @ parameters in Annotations use in the API ref.
3. Define all request parameters. Annotate them all with @Parameter.
4. Implement execute() for RUD commands, and execute()/create() for C commands.
TBD
Command placement depends on whether is command is coming as a part of plugin that can be enabled/disabled, or CloudStack core base.
Note that the calls done from the command, should reference only interfaces from cloud-api or cloud-util packages
getCommands()
The commands defined in the plugin, should reference only interfaces located in cloud-api/cloud-utils/<your plugin> packages