cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boris Stoyanov <boris.stoya...@shapeblue.com>
Subject Re: [DISCUSS] API versioning
Date Mon, 05 Jun 2017 06:59:36 GMT
+1 


boris.stoyanov@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.Tutkowski@netapp.com> wrote:
> 
> This sounds like a good idea to me.
> 
>> On Jun 4, 2017, at 8:24 AM, Will Stevens <williamstevens@gmail.com> wrote:
>> 
>> +1. I like it.
>> 
>>> On Jun 4, 2017 5:04 AM, "Rene Moser" <mail@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?
>>> 
>>> 
>>> 
>>> 

Mime
View raw message