Matt, thanks for the email, I +1 on the next page link. Then user needn't build up link by themself.
I also have one more question after review those pagination patches: As those pagination proposes change the default sort order. So should we keep the sort order for old version API? I think it should be yes. For instance-actions, it should keep the order sorted by 'create_at' column in old versionAPI. The new version API will sort the result by 'updated_at' column. But the question for keypairs and hypervisors, looks like they didn't specify the sort order explicitly, so I think they should depend on the DB implementation. Should we keep the old version API unspecified sort order? 2016-06-28 3:07 GMT+08:00 Matt Riedemann <mrie...@linux.vnet.ibm.com>: > There are at least two changes up that add paging support to the API, one > for hypervisors and one for keypairs. Alex Xu pointed out in one of them > that they didn't have a 'next' link in the response for paging, which is > created here for the server/image/flavor view builders: > > > https://github.com/openstack/nova/blob/6e8c84d0cd7651b465cf9bb7ad68a9b24b3658c9/nova/api/openstack/common.py#L448 > > None of the REST API big-whigs were in channel for me to confirm, but I > assume we want this in any API that supports paging. Yes? > > -- > > Thanks, > > Matt Riedemann > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev