Clarifications on use of &page URL parameter

dev
1

First time poster, so forgive me if I am doing this entirely wrong.

I was trying to pull down our users via https://discuss.elastic.co/admin/users/list/all.json?api_key=KEY&api_username=USER which is working fine. However I have two problems when dealing with pagination and I could do with some clarification.

  1. https://discuss.elastic.co/admin/users/list/all.json?api_key=KEY&api_username=USER&page=0 and https://discuss.elastic.co/admin/users/list/all.json?api_key=KEY&api_username=USER&page=1 seem to return the same thing.
  2. https://discuss.elastic.co/admin/users/list/all.json?api_key=KEY&api_username=USER&page=9999999 returns a HTTP 200, but no body, because the page count doesn’t go that high.

I don’t seem to see anything in the response body or headers to indicate what the first/next/last page is. And the docs only say it takes an integer (buts accepts negative ones too).

Appreciative of any guidance that can be offered :slight_smile:

1 Like
2

The page param starts at 1. If it’s less than 1, it’s assumed to be page 1. (Code here.) And you’re right that we don’t return any attribute saying how many pages there are, so I guess the best thing right now is to stop when you find a page with less than 100 results.

6 Likes
3

Thanks for that response :slight_smile:

4

Just an idea for a possible feature request: Would it be reasonable to implement this the way Github builds pagination? Over there, the returned header gives you feedback about the next fetched page (“links”). Rationale for them is to serve each request on its own, without “page guessing”.

Example client code:

https://github.com/Icinga/icinga2/blob/master/changelog.py#L65

5

Front page /latest already does this, totally open to have all pagination APIs follow the same pattern as front page does.

2 Likes