> +
> + public Integer getVirtualCpuCores() {
> + return target.getVirtualCpuCores();
> + }
> +
> + public Integer getVirtualCpusUsed() {
> + return target.getVirtualCpusUsed();
> + }
> +
> + public Integer getVirtualRamInMb() {
> + return target.getVirtualRamInMb();
> + }
> +
> + public Integer getVirtualRamUsedInMb() {
> + return target.getVirtualRamUsedInMb();
> + }
We could remove them, but they are present to make life easier. Let me just
explain the purpose of these domain objects:
The Abiquo API is based on a HATEOAS design. All XML/JSON representations
returned by the api contain links that express relationships with other
entities. A VirtualMachine representation, for example, may have links like:
...
<link rel="disk0" type="application/vnd.abiquo.harddisk+xml"
href="http://endpoint/api/cloud/disks/id0"; />
<link rel="disk1" type="application/vnd.abiquo.harddisk+xml"
href="http://endpoint/api/cloud/disks/id1"; />
...
Many operations against the API require the manipulation of those links:
performint a GET operation to read the values of the related entity, or just
adding/removing links from the representation and then send a PUT request (for
example, this is how NIC or Disk attachment works in Abiquo; just send a
definition with the appropriate links).
All this link manipulation can be too complex and may make the API difficult to
use, so this "Domain Objects", do that work for the user. These Domain Objects
are just decorators of the XML/JSON representations returned by the Abiquo API
(the "target" object) to add this behavior. Having the "getter" delegates is
just convenience to allow users to just operate with the domain objects without
having to unwrap the target object each time a property value is accessed.
Makes sense?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/10/files#r4962753
