12-02-2021 07:36 PM
Hi everyone,
I am using the REST Get snap and it works beautifully for paginated data requests (using the Has Next boolean field and the Next URL field).
I noticed that for some strange reason the REST Post counter-part snap doesn’t have this functionality.
Even though it is less common to hit an HTTP POST endpoint for pagination purposes, I have several APIs that we need to get into production that require a POST and pagination.
Could this functionality being added using the same logic and code (for re-use / lower LOE)?
Thanks in advance!
P.S. I am getting access to Snaplogic support directly and will likely be able to open tickets and feature requests but I am kind of secondary for our company in terms of vendor feature requests, so I think the forum is appropriate. If you need our lead Snaplogic aligned contacts to open a formal feature request, please let me know.
09-17-2022 07:09 AM
Kurt, did this get turned into a feature request that I could up-vote, or did you get a good alternative solution from support? I have the same issue with the Dropbox Business API List Members endpoint.
I have a workaround but it is rather unsatisfying. It requires three pipelines, nested two deep, and saves the cursor state between POSTS in a database table. I could avoid the issue with the cursor if Execute Pipeline supported recursion, but it doesn’t.
-Les
09-19-2022 05:25 AM
@llacroix - I can say that we have a new Snap Pack that is under development that supports paginated REST Post requests. I do not have the release timing yet for this particular feature, but it is definitely on the list of features to be included.
For now an acceptable workaround is to create a child pipeline that has the REST Post snap (and any other applicable logic) and create a triggered task for it. Then call that triggered task from your main pipeline using REST Get with appropriate pagination based on the response.
12-07-2023 01:39 PM
@koryknick - was the Snap Pack supporting paginated REST Post requests ever released?
09-23-2022 09:10 AM
@koryknick Thanks for the workaround idea. I haven’t had a chance to try it, but it makes perfect sense after I read through it a couple of times. Basically the child pipeline acts as a proxy/wrapper to the eventual API endpoint, translating at the protocol level.