If I have a custom query parameter like this for the language
https://api.twitch.tv/helix/streams?language=en
Do I need to include language=en
with pagination or just use the after token?
https://api.twitch.tv/helix/streams?after=TOKEN
If I have a custom query parameter like this for the language
https://api.twitch.tv/helix/streams?language=en
Do I need to include language=en
with pagination or just use the after token?
https://api.twitch.tv/helix/streams?after=TOKEN
After testing.
You need to include the same parameters
So
https://api.twitch.tv/helix/streams?language=en&after=token
Is correct
but
https://api.twitch.tv/helix/streams?after=TOKEN
is not
Ok, this doesn’t seem like good design to me. How can you “page” results with different parameters? It’s like asking for the 3rd page to a different book. The after
token should store all the previous parameters.
shrug Not staff just tested it and confirmed how to make the second page
Similar “issue” with subscribers endpoint you need to include the broadcaster_id
in each request
Maybe it’s bad design but shrug
Thank you for the help! How do I offer feedback on the API to the developers?
The cursor is merely a reference to positions in the query results, nothing more. So the query takes whatever params you give it to get the results, and then returns the results that are offset by either the before, or after, cursor.
If you don’t send the same params for subsequent requests what you’re essentially doing is pointing to a position in a set of results which may be bigger/smaller than your initial request, so it makes no sense to use a cursor without also sending the params.
The design is perfectly normal, the only issue is if the requesting dev were to incorrectly use them and change what prams they are requesting part way through the pagination process.
Thanks for your response. I understand it doesn’t make sense to have pagination token without the original params. It seems like it makes more sense to have the params encoded in the token since without the original params the token doesn’t make sense. That was my point.
I don’t see why you would want the params encoded in the cursor? You’re accomplishing exactly the same thing in the request except the params would be Base64 encoded, you’re still sending exactly the same data just in a different and non-standard way.
This is the standard way of doing it. Different services may provide cursors in slightly different ways (such as the pagination metadata returning the full before/after URLs including the params already in place for you, others such as Twitch just return the cursor itself).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.