Couple of things we changed for the API refactoring, the goal is to make the
overall code more
Modular and fit the new orchestration architecture, in the mean time, it does
not require the client to
change their existing API to access Cloudstack.
Item 1. For each API command, the original @Implementation is replaced by
@APICommand,
New field "name" is added for the APICommand:
Existing one in 4.0 master:
@Implementation(description = "Adds Swift.", responseObject =
HostResponse.class, since="3.0.0")
New 4.1 with API refactoring:
@APICommand(name = " addSwift", description ="Adds swift",
responseObject = HostResponse.class, since = "3.0.0")
Item 2. @IdentityMapper is removed, @IdentityMapper is used to point to the
DB table directly. e.g.,
Existing in 4.0 master:
@IdentityMapper(entityTableName="data_center")
A New entityType is added to the @Parameter annotation. This new entityType
replaces the previous @IdentityMapper.
Instead of accessing the DB table directly, it uses the new DB views from the
response class.
This new DB views optimize the list commands.
New 4.1 with API refactoring:
@Parameter(name=ApiConstants.ZONE_ID, type=CommandType.UUID,
entityType=ZoneResponse.class, ....)
Item 3. In the @Parameter annotation, some type fields have changed
from long to UUID (because we will use UUID instead of Internal ID).
Existing in 4.0 master:
@Parameter(name=ApiConstants.ZONE_ID, type=CommandType.long,
required=true, description="availability zone for the
virtual machine")
New 4.1 with refactoring:
@Parameter(name=ApiConstants.ZONE_ID, type=CommandType.UUID,
entityType=ZoneResponse.class,
required=true, description="availability zone for the
virtual machine")
Item 4. Regoup of the commands. In existing master, all api commands are flat
in one directory. Now they are grouped according to
Their functionality into several groups under:
org.apache.cloudstack.api.command
Item 5. Add the new @ACL annotation for the access control check.
I will add them to the wiki page.
Thanks,
-Fang
-----Original Message-----
From: David Nalley [mailto:[email protected]]
Sent: Friday, December 28, 2012 2:22 PM
To: [email protected]
Cc: sebgoa
Subject: Re: API Updates: Tracking progress, changes
On Fri, Dec 28, 2012 at 4:28 PM, Rohit Yadav <[email protected]> wrote:
> Hi Sebastien,
>
> On 28-Dec-2012, at 2:15 AM, sebgoa <[email protected]> wrote:
>
>> Hi Rohit,
>>
>> I have been following the thread but I have a silly question, maybe you can
>> help clear my confusion :)
>>
>> Does your work impact the client side API ?
>
> Yes and no. Because the way queries were processed is slightly difference
> inside API server, but as far as over the wire aka client requests are
> concerned there is no change in that. There is only enforcement on apis that
> were introduced since 3.x (all of them have an annotation @Implementation
> which is now @APICommand which has a "since=" field which holds the version
> no. they were introduced) to accept only uuids as params wherever applicable.
>
>> Meaning if I am using jclouds, boto, python-cloudstack etc....as clients.
>> Will my client codes break with this API changes ?
>
> With the recent vote and fixes after that, the client code *should not
> break*. If it does it's a bug.
> Behaviour and functionality wise the clients and users should not feel any
> difference.
>
> There will be few changes in the response, which Min would be in a better
> position to explain.
>
Can we get a canonical list of what all of the changes will be?
--David
