+1
boris.stoya...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue > On Jun 4, 2017, at 7:15 PM, Tutkowski, Mike <mike.tutkow...@netapp.com> wrote: > > 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? >>> >>> >>> >>>