Paginazione con API

È stato scritto molto sul tema della paginazione api. Penso che sia giusto dire che l'approccio ingenuo 'ottieni pagina 5, 20 elementi per pagina' non funziona bene con dati variabili, filtri, ordinamento ecc.

cioè

• se ottengo 20 elementi e poi applico un filtro, non ho 20 elementi
• se richiedo la pagina 2 dei dati ordinati, devo anche inviare quello che sto ordinando
• se viene aggiunto un nuovo record mentre eseguo il paging, tutte le pagine successive al record vengono modificate. Mi mancherà (per la cancellazione) o vedrò i record di ripetizione mentre sfoglio la pagina.

L'impaginazione è una funzione del set di dati totale, eppure la ragione per cui stiamo facendo l'impaginazione è che non dobbiamo ottenere l'intero set di dati in una sola volta.

Se si desidera una soluzione che funzioni perfettamente, è necessario che il lato server ricordi il set di dati totale per la query specifica e quindi restituisca le pagine da esso come richiesto. Quindi si invia una richiesta per "pagina 5 della query 1234"

Che può consumare molta memoria.

Non c'è davvero una buona soluzione che ho visto per i dati dinamici. Opterei per:

• un download completo e consente al client di eseguire tutte le impaginazioni
• un'interrogazione completa lato server con filtri e ordinamento, risultati della cache e ritorno per pagina
• un download in streaming / infini-scroll in cui il client ottiene continuamente la pagina successiva di dati

L'esperienza utente per qualcuno che sfoglia i dati, può essere abbastanza fastidiosa quando vedono 19 dei 20 elementi previsti o un elemento ripetuto dall'ultima pagina. Li fa pensare che l'applicazione sia rotta e dovrebbe essere evitata.

Se il tuo URI per l'accesso agli ordini è /api/orders , allora raccomanderei che la pagina 1 degli ordini sia /api/orders/page/1 .

Quindi, per comodità, se usi lo stesso URI per le richieste put, post ed delete, potresti farlo funzionare come se l'URI fosse effettivamente /api/orders (dove applicabile, ovviamente).

Direi di non consentire all'utente di impostare il numero di elementi per pagina (semplice è meglio a mio modesto parere), tuttavia, se questo potrebbe essere qualcosa che desideri fare, potresti aggiungere un parametro opzionale per impostare gli elementi per pagina, quindi:

/api/orders/page/5?itemsPerPage=20

Il cercapersone in ambienti multiutente in cui i dati possono cambiare tra le richieste di pagine è alquanto complicato, nel peggiore dei casi inutile.

La tua prima richiesta ti ha dato una pagina di 10 elementi su un totale di 100. Ora fai un'altra richiesta per la seconda pagina di 10 elementi, ma il numero di elementi è cambiato in 101, con il nuovo elemento esistente in quale sarebbe la prima pagina.

Ora, cosa ritorni? La richiesta era senza dubbio intesa per 10 record non ancora recuperati, ma in caso di restituzione o meno di quel nuovo record? In altre parole, dovremmo restituire i record 12-21, 12-20 + il nuovo record, 10 record a partire dal nuovo record, record 11-20 o cosa?

Applicazioni come Twitter gestiscono semplicemente restituendo i X punti dati più recenti e consentendo agli utenti di recuperarne di più alle estremità come desiderato, ma i loro dati sono strutturati in modo tale che nessun dato si adatti ad un intervallo già recuperato (o se lo fa , come quando si segue qualcuno che è stato pubblicato in quell'intervallo, semplicemente lo ignorano.

Se la tua applicazione può recuperare i dati in base a filtri personalizzati e sequenze di ordinamento, questa non è ovviamente un'opzione, e i problemi che ho descritto iniziano ad aumentare la loro brutta testa. In questi casi, una soluzione ibrida in cui si seleziona un'ampia porzione di dati utilizzando solo filtri che non causano una situazione in cui nuovi dati possono entrare nel blocco, quindi il filtro e l'ordinamento ulteriormente sul client sono spesso la soluzione migliore.

Nel complesso, quindi, non esiste il modo migliore. Dipende molto dai tuoi dati, dai requisiti di presentazione per esso e dal carico accettabile della rete (restituendo volumi di dati più grandi, naturalmente, significa un carico di rete più elevato) e requisiti di sicurezza (in alcuni domini, viene considerato che restituisce più dei dati minimi assoluti per il cliente un rischio per la sicurezza).

What is best or common way to handle pagination on rest api?

RFC 5005 descrive le relazioni di collegamento per comunicare la semantica dei collegamenti di paginazione ai client generici. Sembra come ci si aspetta: ogni relazione include un identificatore della risorsa della pagina appropriata.

Inoltre, introduce in modo specifico una distinzione tra i feed paged (che sono lossy) e archived feed (che non sono lossy). Ciò offre ai clienti un modo per scegliere la strategia appropriata per il loro caso d'uso.

Come hai notato, ciò non risolve il problema di scegliere gli identificatori corretti da usare. Un buon approccio è descritto in Gestione delle tempistiche .

Potresti usare le intestazioni, suppongo, ma questo è il tipo di cosa che mi aspetterei di vedere nell'effettivo identificativo della richiesta; ogni "pagina" è una risorsa diversa e i metadati ti consentono di controllare le regole di memorizzazione nella cache per le diverse pagine dall'origine.