Pagination with HTTP Client

[Henchway]

Hi,

I’m not able to access the original document during pagination with the HTTP Client. This worked with the REST Client, but looks like it’s not possible any more.

This is a needed feature when the API being called does not respond back with limit/offset/next url, but rather only responds with the total number of elements and a data array. Without accessing a previous document (e.g. $original.offset), pagination is not really possible without a rather odd workaround I found:

Namely that I also send the offset as header, which I then access through $_debug in the pagination and thus increment it by the page size for the next call.

(parseInt($_debug.request.headers.find(x => x.keys().pop() == 'X-OFFSET')['X-OFFSET']) + parseInt(_pageSize)).toString()

Does anyone have a better solution for this (except reverting back to using the REST Get Snap)?

Best regards
Thomas

[MattB · Accepted solution]

In similar scenarios when the endpoint does not return the necessary info to determine the the ‘next page’ request directly I have used

snap.in.totalCount

I think in your scenario, the value returned by the above multiplied by the _pageSize pipeline parameter would equate to the Offest value you require for the next ‘next page’ request.

Matt.

[Henchway]

Hi Matt,

thank you very much, I couldn’t solve it with snap.in.totalCount, but snap.out.totalCount did the trick.

For people searching this in the future, here is the configuration. Specifically this is used with the Workday REST API.

Best regards
Thomas