On 12/27/2012 02:11 PM, Rohit Yadav wrote:
Hi,
-1 with a comment: To deprecate an api function, you have two methods (probably more, but these are common):

1. overload the function to accept both UUID and ID, which gives you backwards compatibility forever, but is cumbersome to maintain. 2. Deprecate the old method in a release schedule, giving people an interim and a drop-dead date such as:

"UUID and ID will be accepted as arguments to API Calls in versions 4.x-4.x, then at 4.xx, UUID will be the only method."

This gives a line in the sand that once crossed only UUID works, and gives people time to migrate. That's historically my preference for deprecating existing API function arguments.

Nik


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.




--

Regards,

Nik

Nik Martin
nfina Technologies, Inc.
+1.251.243.0043 x1003
http://nfinausa.com
Relentless Reliability

Reply via email to