[reipahb]

Actually, deleted orders are not a problem with continuation tokens. The deleted order is only an issue if you use traditional paging requests, which was the point of the article.

The only case I can currently think of that cannot be solved using continuation tokens sent to the client is where the order of the items that are enumerated may change between calls to the API. For example, imagine that you are fetching items sorted by score, and somebody upvotes or downvotes an item while you are enumerating them. In that case it is very difficult to encode enough information in the continuation token. (I can think of complicated ways to make it work, but the resulting database queries would be horrible.)

But for simple stuff like deleted items and similar, it is easy. If you leave out sorting it is trivial to implement as well -- all you need is to enumerate the items based on an internal ID that is guaranteed to always increase, filtering them as required. The continuation token will simply be the ID of the last item you evaluated and the filter that is applied. On the next request you just resume from that ID. If that item ID happens to be deleted in the meantime it is no problem. You just resume from the next one available. I.e.:

  SELECT * FROM items WHERE id > :last_returned_id AND [insert-filter-here] ORDER BY id LIMIT 100;

[quesera]

I understand where you're going, but this is not a continuation in the formal sense, and it isn't even usefully similar.

If the client stores the state on behalf of the server, the server will potentially be working with a modified dataset on the next request, and we're right back where we started with limit and offset.

You can cook up a scheme to make it work for a restricted range of requests, but the compromises are severe.