cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tutkowski, Mike" <Mike.Tutkow...@netapp.com>
Subject Re: [DISCUSS] API versioning
Date Tue, 06 Jun 2017 15:55:59 GMT
Yeah, I think the phrase is that CloudStack’s API uses “conditional parameters.” As Syed
notes, based on the presence of, say, parameter X, it may be required that parameters Y and
Z are also passed in.

On 6/6/17, 9:44 AM, "Syed Ahmed" <sahmed@cloudops.com> wrote:

    The interesting thing about Cloudstack's API is that not all parameters are
    required and based on what is being used, a set of parameters is required.
    For example: take the createVolume API.
    
    If you are creating a new volume, the required args are: {*diskofferingid,
    zoneid**}  *and if you use a snapshot to create the volume, the required
    args are {*snapshotid*} This kind of dependency is very hard to represent
    in Swagger. I haven't found any tool that correctly represents the relation
    between different args as yet. Do you guys have any idea?
    
    On Mon, Jun 5, 2017 at 2:23 PM, Ron Wheeler <rwheeler@artifact-software.com>
    wrote:
    
    > Are you thinking of using OpenAPI(Swagger) to do the documentation?
    >
    > Ron
    >
    > On 05/06/2017 10:14 AM, Rafael Weingärtner wrote:
    >
    >> This might be a good excuse for an ACS 5.0! Maybe with some other
    >> additions
    >> such as the support for OASIS CAMP or TOSCA?
    >>
    >> It would be interesting to have a ROADMAP with these desires/wishes.
    >>
    >> On Mon, Jun 5, 2017 at 8:52 AM, Simon Weller <sweller@ena.com.invalid>
    >> wrote:
    >>
    >> +1. Echoing what Rohit pointed out, we have a lot of cleanup to do :-) It
    >>> certainly makes it a lot easier though when you're not breaking
    >>> compatibility with existing code.
    >>>
    >>> ________________________________
    >>> From: Rohit Yadav <rohit.yadav@shapeblue.com>
    >>> Sent: Monday, June 5, 2017 4:04 AM
    >>> To: dev@cloudstack.apache.org
    >>> Subject: Re: [DISCUSS] API versioning
    >>>
    >>> +1 Good idea, though bear in mind there are 500+ APIs with no
    >>> modern-RESTful-standardization, a lot of work.
    >>>
    >>>
    >>> Regards.
    >>>
    >>> ________________________________
    >>> From: Nitin Kumar Maharana <nitinkumar.maharana@accelerite.com>
    >>> Sent: 05 June 2017 12:37:24
    >>> To: dev@cloudstack.apache.org
    >>> Subject: Re: [DISCUSS] API versioning
    >>>
    >>> This looks good. +1
    >>>
    >>> rohit.yadav@shapeblue.com
    >>> www.shapeblue.com<http://www.shapeblue.com>
    >>> [http://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]<
    >>> http://www.shapeblue.com/>
    >>>
    >>> Shapeblue - The CloudStack Company<http://www.shapeblue.com/>
    >>> www.shapeblue.com
    >>> The city of Prague was the venue for the spring meeting of the Cloudstack
    >>> European user group. There was
    >>>
    >>>
    >>>
    >>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
    >>> @shapeblue
    >>>
    >>>
    >>>
    >>> On 04-Jun-2017, at 2:34 PM, 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?
    >>>>
    >>>>
    >>>>
    >>>>
    >>>
    >>>
    >>> DISCLAIMER
    >>> ==========
    >>> This e-mail may contain privileged and confidential information which is
    >>> the property of Accelerite, a Persistent Systems business. It is intended
    >>> only for the use of the individual or entity to which it is addressed. If
    >>> you are not the intended recipient, you are not authorized to read,
    >>> retain,
    >>> copy, print, distribute or use this message. If you have received this
    >>> communication in error, please notify the sender and delete all copies of
    >>> this message. Accelerite, a Persistent Systems business does not accept
    >>> any
    >>> liability for virus infected mails.
    >>>
    >>>
    >>
    >>
    > --
    > Ron Wheeler
    > President
    > Artifact Software Inc
    > email: rwheeler@artifact-software.com
    > skype: ronaldmwheeler
    > phone: 866-970-2435, ext 102
    >
    >
    

Mime
View raw message