What is your suggestion?

We should only use one standardized method of pagination across the API, preferably we'd keep the cursor based pagination and drop support foroffset.

Another approach would be to return pagination metadata in the API responses, for instance, something like:

{"page": {"current_number":2,"total_pages":10,"current":"/api/path?limit=10&after_id=xxx","next":"/api/path?limit=10&after_id=yyy","previous":"/api/path?limit=10&after_id=zzz"  }}

Why do you want this feature?

This was discussed in#1308 and@spikecurtis had good motivations for only keeping one (#1308 (comment)), according to@presleyp it may suffice to only keep cursor based pagination around (#1308 (comment)).

Having two methods for pagination can be confusing and hard to enforce on the API side across all endpoints. It might also add complexity if we introduce more advanced features, like sorting on column.

I think it would be good if@Emyrk had a chance to give his two cents as developer of the original implementation.

The issue described in#1357 may also need to be considered here.

Are there any workarounds to get this functionality today?

No.

Are you interested in submitting a PR for this?

After we have consensus on what approach to take? Sure.