Forum Discussion

Henchway's avatar
Henchway
Contributor
3 years ago
Solved

Pagination with HTTP Client

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

2 Replies

  • MattB's avatar
    MattB
    New Contributor II
    3 years ago
    Copy Link

    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's avatar
      Henchway
      Contributor
      3 years ago
      Copy Link

      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