I thinks that’s what the article is saying. I found the descriptions didn’t really explain the differences very well.
We use a cursor that combines the sort key and normally the ID as a secondary sort and pointer value, otherwise you can’t paginate through data where the sort column has duplicates. We don’t really do much to obfuscate these, but we don’t document the structure and people who try to tweak the values won’t get far.
One advantage of opaque cursors is that they can include information that's not part of your public API. For instance, if you allow soft deletes and do not return deleted items in the list, you can end up with a massive stretch of deleted items separating two live results. You can leave a note in the cursor indicating what record was last scanned, and that's not possible in keyset pagination.
> So cursor pagination is just keyset pagination, except instead of using a column value directly you use an opaque string that gets translated back to a column value.
HashIds is a popular solution if those columns are numerical or can be represented numerically (e.g. timestamp).
Compare with: <https://datatracker.ietf.org/doc/html/draft-peabody-dispatch...>
Re:Paginating Requests in APIs (2020)
by ignaciochiazzo on Tuesday May 31, 2022 @11:38PM
(#31577777)
Hey thanks for the feedback. I will update the article.
That said I'm not sure if everyone agrees on that definition, from what I know people do consider keyset pagination and cursor pagination to basically mean the same thing.