We can just agree from now on to use the ³id" for handling multiple ids. And of course, we can never delete the ³ID² parameter just to satisfy the old convention, as this is the most used parameter :)
I can see that several existing commands - archive/deleteAlerts are using ApiConstants.IDs parameter. We can mark IDs as deprecated, so its no longer used by new commands. -Alena. On 2/7/14, 11:03 AM, "Koushik Das" <koushik....@citrix.com> wrote: >Good point Min. >I also thought about it but looking at some of the existing APIs thought >of keeping both. > >For e.g. in deploy VM api there is a parameter called 'networkids' which >can take an array of network IDs. Note that the naming convention of >ending in 's'. Now by this logic we should name the parameter 'ids' and >remove the existing parameter 'id' which will be a breaking change. In >case the existing 'id' parameter is used for multiple IDs that breaks the >parameter naming convention. > >I am all in favour of using the existing 'id' parameter if there is no >issues with breaking the naming convention. > > >On 07-Feb-2014, at 11:25 PM, Min Chen <min.c...@citrix.com> wrote: > >> Hi Koushik, >> >> I agree with the idea of supporting multiple IDs. But I may not like >>the >> idea of introducing another different query parameter "ids" for this >> purpose. Why cannot we just change current "id" parameter to take a list >> of values? This way, user will not need to use two different parameters >> for single or multiple cases. Maintaining two different parameters for >> similar purpose is error-prone. If you look at Amazon EC2 api, you will >> notice that they are also using the similar convention, id parameter can >> be one or more. >> >> Thanks >> -min >> >> On 2/6/14 3:24 AM, "Koushik Das" <koushik....@citrix.com> wrote: >> >>> Yes it will be like a findByIds() and the one id case is just a special >>> case for this. >>> >>> On 06-Feb-2014, at 4:24 PM, Daan Hoogland <daan.hoogl...@gmail.com> >>> wrote: >>> >>>> looks nice, it will be backed by the current query for one id? or will >>>> you write a findByIds()? >>>> >>>> On Thu, Feb 6, 2014 at 9:35 AM, Abhinandan Prateek >>>> <abhinandan.prat...@citrix.com> wrote: >>>>> +1, The listVM call is one of the most resource intensive call. Any >>>>> step >>>>> to optimise it are welcome. >>>>> >>>>> On 06/02/14 2:01 pm, "Koushik Das" <koushik....@citrix.com> wrote: >>>>> >>>>>> Currently list VM can only be called using a single VM ID. So if >>>>>> there is >>>>>> a need to query a set of VMs using ID then either multiple list VM >>>>>> calls >>>>>> need to be made or all VMs needs to be fetched and then do a client >>>>>> side >>>>>> filtering. Both approaches are sub-optimal - the former results in >>>>>> multiple queries to database and the latter will be an overkill if >>>>>>you >>>>>> need a small subset from a very large number of VMs. >>>>>> >>>>>> The proposal is to have an additional parameter to specify a list of >>>>>> VM >>>>>> IDs for which the data needs to be fetched. Using this the required >>>>>> VMs >>>>>> can be queried in an efficient manner. With the new parameter the >>>>>> syntax >>>>>> would look like >>>>>> >>>>>> >>>>>>http://localhost:8096/api?command=listVirtualMachines&listAll=true&id >>>>>>s= >>>>>> edd >>>>>> >>>>>>ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba013 >>>>>>4 >>>>>> >>>>>> The new 'ids' parameter will be mutually exclusive with the existing >>>>>> 'id' >>>>>> parameter. >>>>>> >>>>>> Let me know if there are any concerns/comments. >>>>>> >>>>>> Thanks, >>>>>> Koushik >>>>> >>>> >>>> >>>> >>>> -- >>>> Daan >>> >> >
