Re:Paginating Requests in APIs (2020)
by dodobirdlord on Saturday May 28, 2022 @11:15PM
(#31546015)
Your second point is noted in the https://google.aip.dev/158 guidance.
> Request messages for collections should define a string page_token field, allowing users to advance to the next page in the collection.
> * If the user changes the page_size in a request for subsequent pages, the service must honor the new page size.
> * The user is expected to keep all other arguments to the RPC the same; if any arguments are different, the API should send an INVALID_ARGUMENT error.
Expiring tokens has a section in that link:
> Many APIs store page tokens in a database internally. In this situation, APIs may expire page tokens a reasonable time after they have been sent, in order not to needlessly store large amounts of data that is unlikely to be used. It is not necessary to document this behavior.
Re:Paginating Requests in APIs (2020)
by ignaciochiazzo on Tuesday May 31, 2022 @11:40PM
(#31577783)
Hey! Nice! I do think clients shouldn't store the cursor. This technique is neat, I will add it as an option to the Article (I’m the author).
Also I'll add that if you support a pagination API that accepts args (e.g. to filter on different dimensions) you should include a hash of the args in the opaque next page token, and fail the call if the args change. This prevents some nonsense scenarios where you started paging by scanning index A but the user switched filters such that you'd instead scan index B, but you don't have the key for that column.