Nearly all web APIs get paging wrong

11–12 of 12 posts

Re: Nearly all web APIs get paging wrong

#11

Post by karmakaze » Sun, May 10, 2015, 2:37 AM UTC

reipahb wrote: post #6

karmakaze wrote: post #4

I've often wondered how the paging on HN could be better. The main issue is going from page 1 to page 2 where items move between them and I either see items a second time, or miss them. The problem with fixing a sequence on first page load is then when to refresh for new content--only on page 1? Lastly, a prescription is not helpful without a design for efficient implementation. How can this be achieved in a stateles…

The only way I see to solve this without server side state is to replace the page-parameter with a list of items you have seen. The more button would then just find the top 30 items you haven't previously seen. Unfortunately, this would become unwieldy very quickly, and sooner or later you hit the browser limitations on maximum URL size. A relatively simple approach that involves server side state is to periodically…

This solution satisfies my usage and doesn't use a continuation token, though one could be constructed from version and page. It does however expire.

I can see that the other comments on constructing continuation tokens won't work for HN assuming post upvotes are mutably updated.

Re: Nearly all web APIs get paging wrong

#12

Post by quesera » Sun, May 10, 2015, 6:00 AM UTC

reipahb wrote: post #10

mateo411 wrote: post #9

Earlier quoted context omitted.

Ok, I see the difference. You suggest that the continuation token, is basically an encoding of the query parameters, to fetch results from the API. If you go with this approach, then you don't have to store any state on the server. This is a good approach, because it's simple, but it doesn't solve the issue, where the response from the API changes while you making the paging API calls. The example used in the article…

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 it…

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.

Post reply on HN