<html><body>
<p><font size="2" face="sans-serif">The neturon spec appears to be a copy/paste of the nova spec</font><font size="2" face="sans-serif"> that I wrote. Based on the conversation below, I agree that this is not the best approach: GET /<prefix>/<resource_name>/count</font><br>
<br>
<font size="2" face="sans-serif">I'll get started on updating the nova spec to include the total count value in some new attribute based on the existence of a query parameter (ie, </font><font size="2" face="sans-serif">include_count=1</font><font size="2" face="sans-serif">).</font><br>
<br>
<font size="2" face="sans-serif">The details will have to be in limbo a bit until this gets resolved: </font><font size="2" face="sans-serif"><a href="https://review.openstack.org/#/c/133660/">https://review.openstack.org/#/c/133660/</a></font><br>
<br>
<font size="2" face="sans-serif">Thanks,</font><br>
<font size="2" face="sans-serif">Steven Kaufer</font><font size="2" face="sans-serif"><br>
</font><br>
<br>
<tt><font size="2">Sean Dague <sean@dague.net> wrote on 11/20/2014 10:48:05 AM:<br>
<br>
> From: Sean Dague <sean@dague.net></font></tt><br>
<tt><font size="2">> To: openstack-dev@lists.openstack.org</font></tt><br>
<tt><font size="2">> Date: 11/20/2014 10:57 AM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] [api] Counting resources</font></tt><br>
<tt><font size="2">> <br>
> I'm looking at the Nova spec, and it seems very taylored to a specific<br>
> GUI. I'm also not sure that 17128 errors is more useful than 500+ errors<br>
> when presenting to the user (the following in my twitter stream made me<br>
> think about that this morning -<br>
> <a href="https://twitter.com/NINK/status/535299029383380992">https://twitter.com/NINK/status/535299029383380992</a>)<br>
> <br>
> 500+ also better describes the significant figures we're talking about here.<br>
> <br>
> -Sean<br>
> <br>
> On 11/20/2014 11:28 AM, Morgan Fainberg wrote:<br>
> > The only thing I want to caution against is making a SQL-specific<br>
> > choice. In the case of some other backends, it may not be possible (for<br>
> > an extremely large dataset) to get a full count, where SQL does this<br>
> > fairly elegantly. For example, LDAP (in some cases) may have an<br>
> > administrative limit that will say that no more than 10,000 entries<br>
> > would be returned; likely you’re going to have an issue, since you need<br>
> > to issue the query and see how many things match, if you hit the overall<br>
> > limit you’ll get the same count every time (but possibly a different<br>
> > dataset).<br>
> > <br>
> > I want to be very careful that we’re not recommending functionality as a<br>
> > baseline that should be used as a pattern across all similar APIs,<br>
> > especially since we have some backends/storage systems that can’t<br>
> > elegantly always support it.<br>
> > <br>
> > Personally, I like Gerrit’s model (as Sean described) - with the above<br>
> > caveat that not all backends support this type of count.<br>
> > <br>
> > Cheers,<br>
> > Morgan<br>
> > <br>
> >> On Nov 20, 2014, at 8:04 AM, Salvatore Orlando <sorlando@nicira.com<br>
> >> <<a href="mailto:sorlando@nicira.com">mailto:sorlando@nicira.com</a>>> wrote:<br>
> >><br>
> >> The Nova proposal appears to be identical to neutron's, at least from<br>
> >> a consumer perspective.<br>
> >><br>
> >> If I were to pick a winner, I'd follow Sean's advice regarding the<br>
> >> 'more' attribute in responses, and put the total number of resources<br>
> >> there; I would also take Jay's advice of including the total only if<br>
> >> requested with a query param. In this way a user can retrieve the<br>
> >> total number of items regardless of the current pagination index (in<br>
> >> my first post I suggested the total number should be returned only on<br>
> >> the first page of results).<br>
> >><br>
> >> Therefore one could ask for a total number of resources with something<br>
> >> like the following:<br>
> >><br>
> >> GET /some_resources?include_total=1<br>
> >><br>
> >> and obtain a response like the following:<br>
> >><br>
> >> {'resources': [{meh}, {meh}, {meh_again}],<br>
> >> 'something': {<br>
> >> '_links': {'prev': ..., 'next': ...},<br>
> >> 'total': agazillion}<br>
> >> }<br>
> >><br>
> >> where the exact structure and naming of 'something' depends on the<br>
> >> outcome of the discussion at [1]<br>
> >><br>
> >> Salvatore<br>
> >><br>
> >> [1] <a href="https://review.openstack.org/#/c/133660/7/guidelines/">https://review.openstack.org/#/c/133660/7/guidelines/</a><br>
> representation_structure.rst<br>
> >><br>
> >> On 20 November 2014 15:24, Christopher Yeoh <cbkyeoh@gmail.com<br>
> >> <<a href="mailto:cbkyeoh@gmail.com">mailto:cbkyeoh@gmail.com</a>>> wrote:<br>
> >><br>
> >> On Thu, 20 Nov 2014 14:47:16 +0100<br>
> >> Salvatore Orlando <sorlando@nicira.com<br>
> >> <<a href="mailto:sorlando@nicira.com">mailto:sorlando@nicira.com</a>>> wrote:<br>
> >><br>
> >> > Aloha guardians of the API!<br>
> >> ><br>
> >> > I haven recently* reviewed a spec for neutron [1] proposing a<br>
> >> > distinct URI for returning resource count on list operations.<br>
> >> > This proposal is for selected neutron resources, but I believe the<br>
> >> > topic is general enough to require a guideline for the API working<br>
> >> > group. Your advice is therefore extremely valuable.<br>
> >> ><br>
> >> > In a nutshell the proposal is to retrieve resource count in the<br>
> >> > following way:<br>
> >> > GET /<prefix>/<resource_name>/count<br>
> >> ><br>
> >> > In my limited experience with RESTful APIs, I've never encountered<br>
> >> > one that does counting in this way. This obviously does not mean<br>
> >> it's<br>
> >> > a bad idea. I think it's not great from a usability perspective to<br>
> >> > require two distinct URIs to fetch the first page and then the total<br>
> >> > number of elements. I reckon the first response page for a list<br>
> >> > operation might include also the total count. For example:<br>
> >> ><br>
> >> > {'resources': [{meh}, {meh}, {meh_again}],<br>
> >> > 'resource_count': 55<br>
> >> > <link_to_next_page>}<br>
> >> ><br>
> >> > I am however completely open to consider other alternatives.<br>
> >> > What is your opinion on this matter?<br>
> >><br>
> >> FWIW there is a nova spec proposed for counting resources as<br>
> >> well (I think it might have been previously approved for Juno).<br>
> >><br>
> >> <a href="https://review.openstack.org/#/c/134279/">https://review.openstack.org/#/c/134279/</a><br>
> >><br>
> >> I haven't compared the two, but I can't think of a reason we'd<br>
> >> need to be any different between projects here.<br>
> >><br>
> >> Regards,<br>
> >><br>
> >> Chris<br>
> >><br>
> >> ><br>
> >> > Regards,<br>
> >> > Salvatore<br>
> >> ><br>
> >> ><br>
> >> > * it's been 10 days now<br>
> >> ><br>
> >> > [1] <a href="https://review.openstack.org/#/c/102199/">https://review.openstack.org/#/c/102199/</a><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >> OpenStack-dev@lists.openstack.org<br>
> >> <<a href="mailto:OpenStack-dev@lists.openstack.org">mailto:OpenStack-dev@lists.openstack.org</a>><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >> OpenStack-dev@lists.openstack.org<br>
> >> <<a href="mailto:OpenStack-dev@lists.openstack.org">mailto:OpenStack-dev@lists.openstack.org</a>><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > <br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.org<br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > <br>
> <br>
> <br>
> -- <br>
> Sean Dague<br>
> <a href="http://dague.net">http://dague.net</a><br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></tt></body></html>