Page History

...

3. In original FS document, the annotation of entityType in @Parameter points to a resource class, this is replaced by a response class. So entityType points to a response object, and the response class has a one-to-one mapping from the response to the physical entity itself. This translation work is done by the API layer and the entityManagerImpl.

Wiki Markup4. The packages for the new API commands are all moved from the current com.cloud.api.commands to new location: org.apache.cloudstack.api.commands.user.\[group name\]
org.apache.cloudstack.api.commands.admin.\[group_name\]

The responses are also moved to new location at
org.apache.cloudstack.api.response

...

Our goal is that current clients do not need to change their existing API to access Cloudstack.
(I used an example to show the difference for each item in the list. )

1. For each API command, the original @Implementation is replaced by @APICommand, New field "name" is added for the APICommand:

...

There are three files handling the API layer checks and validation: apiServet, apiServer and apiDispatcher.
apiSevlet checks the web access is valid;
If it passes, it goes to the apiServer;
apiServer parses the command annotation, and checks access to the adapter and check if cmd exists;
apiDispatcher has the logic to check the ACL access, the parameter valication, the DB access validation.

...

• We have separated all the API commands into separate groups according to their functionality. All API commands also moved from the previous com.cloud.api.commands packages to org.apache.cloudstack.api\[command.admin\|user\].\{groupname\} \
  - The separation of user and admin commands is for the developers to get better understanding of the commands and the options for commands; \
  - The separation is alos for document generation purpose.

• ACL as a plugin adapter is integrated into API server;

...

• Next we need to add the ACL and validation logic in the command execution context to the apiDispatcher.

Project progress for list api performance optimization

• Removed IdentityProxy fields in all Response classes to avoid internal DB Id to UUID conversion (extra db lookup) in list result serialization phase.

• Created DB views to further speed up the following costly list APIs:
  1. listAccounts
  2. listAsyncJobs
  3. listDomainRouters
  4. listEvents
  5. listHosts
  6. listVmGroups
  7. listProjects
  8. listProjectAccounts
  9. listProjectInvitations
  10. listResourceTags
  11. listSecurityGroups
  12. listUsers
  13. listVirtualMachines
  14. listVolumes
  15. listStoragePools
  16. listZones
  17. listDiskOfferings
  18. listServiceOfferings
• Added a new create-schema-view.sql to create these new DB views during database setup phase.
• Also handled upgrade script for these new DB views in schema-40to410.sql.