Open Stack

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 <mriedem at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160628/28e46d26/attachment.html>