Pagination in a REST API - What's your favorite/most ergonomic approach? pages/counts/offsets, curor-based, etc. - looking to add this to some new @inngest.com API endpoints this week
Comments
Log in with your Bluesky account to leave a comment
obviously depends on the use case, personally I would prefer cursor based pagination.
As a developer - allows me to apply different types of optimization freely (e.g. storing IDs to skip in the cursor), creates artificial constraint to users
As a user - it limits my UX options and gives me less room to make mistakes (e.g. page size = 100k, and waiting forever or showing items multiple times in different pages).
But offset based pagination is so appealing to use, who doesn't want to see the last page of results 😭
Cursor based is great when you have fixed starting point of the pagination. Think a Bluesky feed. I want to see the next 10 posts after POST_1. If I use take/skip, and some of the posts get deleted, I will never get to that POST_1.
If I use a cursor, like a post's ID, my position is fixed.
Interesting points. The initial endpoints will mostly be CRUD type resources that the user manages. Still, my default sort was going to be `updated_at DESC` so it could run into the same issues if resources are modified. I'm leaving custom sort out of the MVP though.
I like cursor based pagination. It really lets you encode all sorts of state in the cursor. For example, you can base64 encode a json object that has offsets, counts, sort information, last ID returned, etc. and it lets you change the pagination cursor to support whatever later.
Interesting idea on b64 encoding data within the cursor. My initial thought was to keep the cursor simple with some sort of id or encoded offset, but encoded json sorts and filters and whatnot sounds like a great idea
Yea! I wish I could take credit for this idea, but it comes from GraphQL where sometimes it’s really complicated to represent all of this state in a handful of variables.
This is helpful - I want to make something that is robust across our entire REST API for folks to depend upon then ideally wrap in our SDK to make it even easier
Comments
The key is people not reverse engineering the cursor value and making assumptions about it.
As a developer - allows me to apply different types of optimization freely (e.g. storing IDs to skip in the cursor), creates artificial constraint to users
But offset based pagination is so appealing to use, who doesn't want to see the last page of results 😭
If I use a cursor, like a post's ID, my position is fixed.