02-06-2023 03:36 AM
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
Solved! Go to Solution.
02-09-2023 01:41 AM
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.
02-09-2023 01:41 AM
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.
03-01-2023 07:03 AM
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