Glad Ben was able to help. In answer to your questions:
ps, when was this put in, I didn’t notice it last month… but that could
just mean my reports have been off for some time!
The pagination has been in place (and documented) since we launched v2 of
the API in April last year.
would you consider allow a GET without pagination… is pagination generally
more useful for UI clients to an API? Programmatic clients have to do more
work to follow the hypermedia breadcrumbs but they’re more flexible as
such?.
Pagination was a deliberate decision early in the design of v2, and it’s
unlikely that we’ll do much in the future beyond possibly changing the page
size limits available.
Considering the huge variance in dataset sizes across different accounts,
if anything it’s more important to provide pagination via the API than
via the UI. If we allowed a page size of “all” for arbitrary account
resources, our developers would have to deal with the fact that they could
be sent hundreds of thousands of entries (with no way of knowing before
request the likely size of the response). They’d be much more likely to
have to accommodate timeouts, dropped connections and so on.
Programmatically traversing links and assembling a full set of data is, if
anything, simpler with an API than via a UI: a developer can store previous
pages, keep track of what page they have already pulled up to and so on.
Once these code paths are set up, they will work without additional effort
by the developer.
There are certainly things we can (and will) do to improve the options to
retrieve data from the API, but pagination is likely to be a feature of
these options for the foreseeable future.
ps, when was this put in, I didn’t notice it last month… but that could
just mean my reports have been off for some time!On Thursday, 5 December 2013 08:22:45 UTC, Toby wrote:
ok thanks, that clears it up.
would you consider allow a GET without pagination (ie, drop the 100
limit?). It’s more work for me to follow the trail in the Link header
programmatically but I realise it could have an affect on your servers
(would you see load issues allowing a single large query version several
small ones?).
It’s an interesting point from an API design perspective though;
is pagination generally more useful for UI clients to an API? Programmatic
clients have to do more work to follow the hypermedia breadcrumbs but
they’re more flexible as such?.
thanks again,
Toby
On Wednesday, 4 December 2013 23:28:45 UTC, Ben wrote:
Hi Toby,
Yes, all API requests that return multiple items are paginated. You can
increase the number of items with the “per_page” param (up to max of 100).
If you still need more items, you’ll need to use the information in the
Link header to make multiple requests.
Yes, all API requests that return multiple items are paginated. You can
increase the number of items with the “per_page” param (up to max of 100).
If you still need more items, you’ll need to use the information in the
Link header to make multiple requests.
would you consider allow a GET without pagination (ie, drop the 100
limit?). It’s more work for me to follow the trail in the Link header
programmatically but I realise it could have an affect on your servers
(would you see load issues allowing a single large query version several
small ones?).
It’s an interesting point from an API design perspective though;
is pagination generally more useful for UI clients to an API? Programmatic
clients have to do more work to follow the hypermedia breadcrumbs but
they’re more flexible as such?.
thanks again,
TobyOn Wednesday, 4 December 2013 23:28:45 UTC, Ben wrote:
Hi Toby,
Yes, all API requests that return multiple items are paginated. You can
increase the number of items with the “per_page” param (up to max of 100).
If you still need more items, you’ll need to use the information in the
Link header to make multiple requests.