incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fang Wang <fang.w...@citrix.com>
Subject RE: API Updates: Tracking progress, changes
Date Thu, 03 Jan 2013 22:10:33 GMT
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:david@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.yadav@citrix.com> wrote:
> Hi Sebastien,
>
> On 28-Dec-2012, at 2:15 AM, sebgoa <runseb@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

Mime
View raw message