Hi all, I updated the API refactoring wiki page with the list. The page https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+API+refactoring It also contains the link to the FS (in doc), where you can find more info regarding this project.
A clarification about the UUID. This is not new in 4.1, we used UUID instead of internal DB id since 3.0.0. We added special handling for pre3.0.0 release where DB id is used, and for post-3.0.0 where UUID is used, So as not to break users with 2.x releases. For each item in the list, I used one example to illustrate it. Thanks, -Fang -----Original Message----- From: Fang Wang [mailto:fang.w...@citrix.com] Sent: Thursday, January 03, 2013 2:11 PM To: cloudstack-dev@incubator.apache.org Subject: RE: API Updates: Tracking progress, changes 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:da...@gnsa.us] Sent: Friday, December 28, 2012 2:22 PM To: cloudstack-dev@incubator.apache.org Cc: sebgoa Subject: Re: API Updates: Tracking progress, changes On Fri, Dec 28, 2012 at 4:28 PM, Rohit Yadav <rohit.ya...@citrix.com> wrote: > Hi Sebastien, > > On 28-Dec-2012, at 2:15 AM, sebgoa <run...@gmail.com> 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
