George, +1 -- my response exactly. The HTTP protocol provides the semantic for this type of information through a HEAD operation.
Thanks, -John On Nov 5, 2012, at 7:02 PM, Jessica Wang <jessica.w...@citrix.com> wrote: > Edison, > > "count" is not referring to how many items in an API response. > "count" is referring to how many items in database. > > e.g. There are 3500 VMs in database. > listVirtualMachines API returns 500 VMs each time (by page parameter and > pagesize parameter). > In this case, "count" will be 3500 instead of 500. > > Jessica > > -----Original Message----- > From: Edison Su [mailto:edison...@citrix.com] > Sent: Monday, November 05, 2012 3:57 PM > To: cloudstack-dev@incubator.apache.org; Min Chen > Subject: RE: Should we have separate "Count" API? > > If we return a list in the list API, e.g. [VM1, VM2, .., VMn], the "count", > or the length of list can be inferred from the list. When I write the python > binding for cloudstack API, I found "count" field is not that usefull. > >> -----Original Message----- >> From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] >> Sent: Monday, November 05, 2012 3:44 PM >> To: cloudstack-dev@incubator.apache.org; Min Chen >> Subject: Re: Should we have separate "Count" API? >> >> Min, >> >> We didn't use separate call as well as didn't use resource count table >> because >> we "count" field represents the number of DB resources matching the search >> criteria (ignoring page/pageSize info) specified in the list* api call. For >> example: >> >> listVirtualMachines&state=Running&hostId=1&page=1&pageSize=1 >> >> In the "count" field we expect to see the only how many vms in Running >> state, running on hostId=1 exist in the system; not the entire number of vms >> in the system that we keep per account in resource_count table. >> And although only one vm object will be returned (as you requested >> page=1&pageSize=1), you'll know how many vms in the system satisfy the >> search criteria. >> >> As variation of parameters depends on particular API call, the count has to >> be >> returned as a part of list* command response. >> >> -Alena. >> >> From: Min Chen <min.c...@citrix.com<mailto:min.c...@citrix.com>> >> Reply-To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack- >> d...@incubator.apache.org>" <cloudstack- >> d...@incubator.apache.org<mailto:cloudstack-dev@incubator.apache.org>> >> To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack- >> d...@incubator.apache.org>" <cloudstack- >> d...@incubator.apache.org<mailto:cloudstack-dev@incubator.apache.org>> >> Subject: Should we have separate "Count" API? >> >> Hi there, >> >> In fixing the bug regarding count of a list API today, I cannot help >> wondering >> why we cannot have separate "Count" api for such purpose rather than >> bundling this information with list API, where we basically return some >> information that some users will just throw away since they only care about >> count for dashboard purpose. I also noticed that in our DB schema, we >> actually have a table "resource_count" there, not sure the original rational >> behind this table. If we can take advantage of this table (and keep the >> information there up-to-date), we may be able to provide a very efficient >> way to implement such "Count' apis for most commonly used cases. >> Any thoughts on this? >> >> Thanks >> -min >
