I think I'm missing something fundamental about how `CursorPagination` is
intended to be used and I'd really appreciate it if someone could chime in
and clear something up for me.

Let's say I have a cursor paginated listing endpoint at `/catphotos/`. New 
cat
photo records are created frequently with a high precision datetime field 
that
the cursor paginator is configured to sort by (`-created`).

I now build some API consumer that, on load, displays the most recent cat
photos. At the bottom of the listing it has a load more button to get the 
next
page of (older) results.

To achieve this, the consumer hits /catphotos/ and displays the first
page of results. If there is a `next` value in the response, it stores that
value so that the load more button knows the location to retrieve the next 
page
of results. If there is no `next` value, the load more button is hidden.
`previous` is always null on this initial call.

In the API consumer, I now add a "Load most recent" button. Ideally, I 
think,
the client would reload the page it started with and check for a new value 
of
`previous` to see if there are newer entries to display. However, the client
doesn't have a canonical URL for the first loaded page (just `/catphotos/` 
which
now likely returns some new result set).

What is the recommended approach for an API consumer to handle this
situation?

* Presumably, I could construct a cursor parameter manually that would 
reference
  the page I initially loaded. I'm assuming, however, that the cursor 
parameter
  is encoded specifically to discourage such behavior.
* If I reverse the sort (`created` vs `-created`), /catphotos/ would always
  display the same page but then consumers have to paginate through all 
pages to
  get the most recent entries.
* I could hit /catphotos/ and paginate until I encounter a record I've 
already
  cached locally and then stop. However, this approach would only be 
practical
  if the volume of new catphotos is relatively low.
* If the CursorPaginator is modified to return a "current" field that 
represents
  the canonical URL for whatever page is currently loaded, the client would 
be
  able to use that field to reload its initial page and check for a new 
value of
  `previous`. (That is to say that `current` is a URL with a cursor 
parameter
  even if the request URL excluded such a parameter).

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to