Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: make linkparsers take response and request as arguments #244

Open
barbich opened this issue Mar 27, 2024 · 0 comments
Open

Comments

@barbich
Copy link

barbich commented Mar 27, 2024

hi
(this might be more out of ignorance on my side than a topic for issue in restish)

I am trying to add a new AddLinkParser to restish to handle pagination in a vendors API (link https://cyber-risk.upguard.com/api/docs). The API in question just returns a counter to the next page token and its fairly easy to build the link the next page out of it. So for example, a query to /domains returns a JSON with next_page_token: 1000 and total_results: 15723
then the next page link would simply be /domains?page_token={next_page_token}

in m code (myparsers), as the myparsers.ParseLinks function has only the query response to work from, I have been setting the the next link by putting the link URI to "?page_token=" + b["next_page_token"].(string), leaving it to restish "links.ParseLink" (in links.go+49) function to build a complete URI using ResolveReference.

So far, so good. This has proven to be fairly easy and working as expected with one gotcha: if my original query contains any parameters, then the ResolveReference squashes those parameters making the Link URI not representative of my original query.

Hence this feature request: make linkparsers take response and request as arguments
If the ParseLinks function being called would have the response and the (original) request as arguments it would allow to build more complex "next" page URIs .

Tx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant