I think it's better to implement the feature first. Current HTTP layer of CloudStack is not REST ready, what I mean is you can not add your endpoint as convenient as in popular MVC like Spring MVC, ruby Rails, java Grails or GlassFish jersey which you mentioned before. So I am afraid that it's hard if you want do something like GET /vm/vm_uuid?state=Running For the query string, instead of inventing our pattern, I suggest following filter API of AWS API, it has answered our question.
> -----Original Message----- > From: Min Chen [mailto:min.c...@citrix.com] > Sent: Monday, November 05, 2012 4:19 PM > To: cloudstack-dev@incubator.apache.org; Alena Prokharchyk > Subject: Re: Should we have separate "Count" API? > > Yes, those are clean REST Urls. But do we have plan to convert our current > API url to standard REST? > > -min > > On 11/5/12 4:12 PM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> wrote: > > >I like the "countOnly" idea. If it were a proper REST API, it would be > >GET /vm/count?state=Running And GET /vm?state=Running > > > >On 11/5/12 4:03 PM, "Min Chen" <min.c...@citrix.com> wrote: > > > >>Thanks Alena. Maybe we should support a query parameter "countOnly" > or > >>something for count only case to avoid issuing extra sql queries. > >> > >>-min > >> > >>From: Alena Prokharchyk > >><alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> > >>Date: Monday, November 5, 2012 3:43 PM > >>To: > >>"cloudstack-dev@incubator.apache.org<mailto:cloudstack- > dev@incubator.a > >>pac > >>h > >>e.org>" > >><cloudstack-dev@incubator.apache.org<mailto:cloudstack- > dev@incubator.a > >>pac > >>h > >>e.org>>, Min Chen <min.c...@citrix.com<mailto:min.c...@citrix.com>> > >>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- > dev@incubator.a > >>pac > >>h > >>e.org>" > >><cloudstack-dev@incubator.apache.org<mailto:cloudstack- > dev@incubator.a > >>pac > >>h > >>e.org>> > >>To: > >>"cloudstack-dev@incubator.apache.org<mailto:cloudstack- > dev@incubator.a > >>pac > >>h > >>e.org>" > >><cloudstack-dev@incubator.apache.org<mailto:cloudstack- > dev@incubator.a > >>pac > >>h > >>e.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 > >> > >
