As I understand there is no classic paging in Cassandra. In order to retrieve further items, one must present a (serializable) token, a result of a previous query.
Does this mean that the classic & neat REST endpoints where we specify page and size in the query parameters are no longer possible? I mean we could iterate over Cassandra (option 1) but this seems very inefficient for long lists, isn't it? Or we should not bother and just do it?
Or, is it now the client responsibility to present the token it got from the last range? This would also mean clients can only navigate back and forth (unless we do some magic like automatic rewinding under the hood which basically implies option 1).
Some of drivers are supporting some kind of this functionality, for example, DataStax Java driver exposes the "paging state" that you can put into query string or cookie, and proceed from where you stopped. Similar functionality exists in drivers for Python, Node.js, C++, and potentially other drivers (didn't check). But these are only "forward" iterators
You can have the rest interface take a "pageToken", being serialized last clustering key you retrieved base64 encoded (or encrypted then encoded if contains sensitive) that you can pass in response. Give pager token and a count and can continue down iteration. It will be efficient and its just replacing the offset. Providing clustering key is smaller it wont look that weird. For an example look at https://developers.google.com/calendar/v3/pagination