Problema di impaginazione nel progetto RESTful API

Question

Sto progettando un'API RESTful per un'applicazione mobile su cui sto lavorando. Il mio problema è con le grandi raccolte contenenti molti oggetti. Capisco che una buona pratica è quella di impaginare un gran numero di risultati in una raccolta.

Ho letto l'API doc Facebook Graph (https://developers.facebook.com/docs/graph-api/using-graph-api/v2.2), Twitter cursori doc (https://dev.twitter.com/overview/api/cursoring), API doc GitHub (https://developer.github.com/v3/) e questo post (API pagination best practices).

Considerare un esempio di raccolta /resources nella mia API che contiene 100 elementi denominati resource1 a resource100 e ordinati decrescente. Questa è la risposta si otterrà su una richiesta GET (GET http://api.path.com/resources?limit=5):

{ 
    "_links": { 
     "self": { "href": "/resources?limit=5&page=1" }, 
     "last": { "href": "/resources?limit=5&page=7" }, 
     "next": { "href": "/resources?limit=5&page=2" } 
    }, 

    "_embedded": { 
     "records": [ 
      { resource 100 }, 
      { resource 99 }, 
      { resource 98 }, 
      { resource 97 }, 
      { resource 96 } 
     ] 
    } 
} 

Ora il mio problema è uno scenario come questo:

1- I GET /resources con contenuti di cui sopra.

2- Successivamente, qualcosa viene aggiunto alla raccolta delle risorse (ad esempio un altro dispositivo aggiunge una nuova risorsa per questo account). Quindi ora ho 101 risorse.

3- I GET /resources?limit=5&page=2 come la risposta iniziale suggerisce conterrà la pagina successiva dei miei risultati. La risposta sarebbe come questo:

{ 
    "_links": { 
     "self": { "href": "/history?page=2&limit=5" }, 
     "last": { "href": "/history?page=7&limit=5" }, 
     "next": { "href": "/history?page=3&limit=5" } 
    }, 

    "_embedded": { 
     "records": [ 
      { resource 96 }, 
      { resource 95 }, 
      { resource 94 }, 
      { resource 93 }, 
      { resource 92 } 
     ] 
    } 
} 

Come si può vedere resource 96 è ripetuto in entrambe le pagine (o un problema simile può accadere se una risorsa viene eliminata nella fase 2, in questo caso una risorsa verranno persi).

Poiché desidero utilizzarlo in un'app mobile e in un elenco, devo aggiungere le risorse di ciascuna chiamata API a quella precedente affinché possa avere un elenco completo. Ma questo è preoccupante. Per favore fatemi sapere se avete un suggerimento. Grazie in anticipo.

P.S: Ho considerato il timestamp come le stringhe di query anziché l'impaginazione basata sul cursore, ma ciò creerà problemi altrove. (fammi sapere se hai bisogno di maggiori informazioni a riguardo)

Answer 1

Perché non mantenere solo una serie di risorse viste?

Quindi quando si elabora ogni risposta è possibile verificare se la risorsa è già stata presentata.

Answer 2

Abbiamo appena implementato qualcosa di simile a questo per un'applicazione mobile tramite un'API REST. L'app mobile ha superato un ulteriore parametro di query che rappresenta un timestamp in base al quale gli elementi della pagina devono essere "congelati".

Così il vostro prima richiesta sarebbe simile GET /resources?limit=5&page=1&from=2015-01-25T05:10:31.000Z e poi la seconda richiesta di pagina (qualche tempo dopo) sarebbe incrementare il numero di pagine, ma mantenere la stessa data e ora: GET /resources?limit=5&page=2&from=2015-01-25T05:10:31.000Z

Questo dà anche il controllo mobile app, se vuole per differenziare una pagina "soft" (preservando il timestamp della richiesta della pagina 1) da una pagina "hard refresh" (reimpostazione del timestamp all'ora corrente).