Forgot to mention, let's keep the voting period open till 7th Jan 2013 12:00 GMT, i.e. as a lot of people are offline.
On 27-Dec-2012, at 12:11 PM, Rohit Yadav <rohit.ya...@citrix.com> wrote: > Hi, > > I'm asking for the community to vote if they want to enforce UUID string to > be used in parameters while querying an API. This would break any client or > script that uses internal ID. AFAIK api response (json or xml, since 3.x for > sure) always have had UUIDs so if any client/script that uses apis to query > entities and base their further operations using ids from the response(s) > should be fine. > > You may vote by: > +1 Agree > 0 No opinion > -1 Disagree > > Some context and description: > > CloudStack uses internal IDs which are long ints and they have a mapping > between this ID and the external ID or UUID which is a random string of > characters. > There are DAO classes which provides a mechanism to query a particular > table(s) and do other operations. There are VO objects which can hold content > of a row. In most VO objects a method getId() would return a long int number > which is the internal ID of that entity and they would have a getUuid() which > returns a unique random string of chars. > > At present an API can be queried with both ids, for example for param > domainid using uuid in 1 and using id in 2: > > 1. > http://localhost:8080/client?command=listResourceLimits&domainid=8664e04a-9931-4765-b3456e6888d0fa1d > 2. http://localhost:8080/client?command=listResourceLimits&domainid=1 > > For querying using id, the caller should have idea of the id for that entity > and which is only possible if they have access to CloudStack's database. > There is no other way of knowing an entity's id, only uuids are sent as ids > in the response. > > Regards. > >
