Page History

...

A pre-requisite to come up with a clean REST style API is to build CloudStack Resource Object Model. This object model should have the following information for each CloudStack resource, including those resources directly managed by CloudStack (like VM, volume, network, etc) and those indirectly related resources (like Domain, Account, etc). Note that NorthBound API and SouthBound API can share the same object model, controlled by different visibility flags.

1. Accessibilty of this resource entity, is it public to the end user or internal to CloudStack internal? For example, PhysicalNetwork should be a resource not public to end user, so API server should not expose a REST url with PhysicalNetwork as the <entity> in above URL pattern.
2. Each resource should be characterized by:
   • Attributes (including its visibility)
   • Relationships (characterizing various different relationships, like association, aggregation, composition, inheritance etc)
   • Supported Methods (including construction, delete, and operations, etc)

With this object model in place, we can have a generic and standard mechanism to

• Construct each Response class, instead of current ad-hoc way based on UI.
• Create cache DB schema or view based on resource response.
• Clearly identify supported methods for each resource.
• Provide a natural map of entity supported methods to REST url pattern. For example, POST create will easily map to the Constructor method of an entity, REST DELETE will map easily to the Delete method of an entity, etc.

Here is a simple Object Model snippet to briefly illustrate the idea: (In the diagram below, entities colored with light blue should serve as our first-level entities that can be exposed to end-user in our REST url pattern, while those entities colored with light brown should be internal to cloud-engine southbound API).
Image Added