This sounds like a good idea to me.

> On Jun 4, 2017, at 8:24 AM, Will Stevens <williamstev...@gmail.com> wrote:
> 
> +1. I like it.
> 
>> On Jun 4, 2017 5:04 AM, "Rene Moser" <m...@renemoser.net> wrote:
>> 
>> Hi
>> 
>> I recently developed ansible modules for the ACL API and ... found this
>> has a really inconsistent API naming. E.g.
>> 
>> createNetworkACL <<-- this creates an ACL rule
>> createNetworkACLList <<-- this create the ACL
>> 
>> updateNetworkACLItem <<-- this updates an ACL rule
>> updateNetworkACLList <<-- this updates the ACL
>> 
>> My first thoughs was, someone has to fix this, like
>> 
>> createNetworkAclRule <<-- this create the ACL rule
>> createNetworkAcl <<-- this creates an ACL
>> 
>> updateNetworkAclRule <<-- this updates the ACL rule
>> updateNetworkAcl <<-- this updates an ACL
>> 
>> But how without breaking the API for backwards compatibility? I know a
>> few other places where the API has inconsistent namings. Fixing the API
>> but in a controlled way? What about by adding a version to the API?
>> 
>> I would like to introduce a API versioning to cloudstack: The current
>> API would be frozen into verison v1. The new API will have v2. The
>> versioned API has the URL scheme:
>> 
>> /client/api/<version>
>> 
>> The current API would be /client/api/v1 and the /client/api would be an
>> alias for v1. This ensures backwards compatibility.
>> 
>> This would allow us to deprecate and change APIs.
>> 
>> Any thoughts?
>> 
>> 
>> 
>> 

Reply via email to