Come dovrebbe essere gestita l'impaginazione che consente il collegamento a pagine arbitrarie in un'API RESTful?

Question

Come dovrebbe essere gestita l'impaginazione che consente il collegamento a pagine arbitrarie in un'API RESTful?

#1 da (3 voti)

2

Come dovrebbe un'API RESTful gestire l'impaginazione nella situazione in cui un cliente può volere la possibilità di passare a pagine arbitrarie? Supponiamo di utilizzare l'intestazione Link nel modo in cui l' API GitHub :

Link: <https://api.github.com/user/repos?page=3&per_page=100>; rel="next", <https://api.github.com/user/repos?page=50&per_page=100>; rel="last"

L'API, come molti altri, restituisce collegamenti alla pagina successiva, alla pagina precedente, alla prima pagina e all'ultima pagina. Ciò non tiene conto del caso d'uso relativamente comune di fornire sui link lato client a un intervallo di pagine e non solo al prossimo / precedente / primo / ultimo. Se, ad esempio, la richiesta restituisce 100 pagine di risultati, il cliente potrebbe voler consentire la possibilità di passare a una pagina arbitraria. Come dovrebbe essere fatto aderendo strettamente ai concetti di REST?

Alcune opzioni possibili:

Lascia che il cliente deduca gli altri link. Hai la prima e l'ultima pagina, potrebbe essere un ragionevole presupposto modificare il link per ottenere le altre pagine. Questo sembra andare contro HATEOAS (che è sempre il principio di REST che sembra causare problemi).
Restituisce un link ad ogni pagina. Questo sembra ingombrante in quanto il numero potenziale di pagine potrebbe essere elevato.
Restituisce un collegamento a un piccolo intervallo di pagine (forse 2 su entrambi i lati della pagina corrente). Questo sembra un approccio relativamente ragionevole, ma limita le opzioni che i client hanno quando si tratta di visualizzare le informazioni di paginazione.

api-design rest

posta James Allardice 05.05.2015 - 21:56

fonte

1 risposta

Leggi altre domande sui tag api-design rest

Approccio di sviluppo per la condivisione di applicazioni GUI su X std :: implementazione non array di vettori?

score 3 · Accepted Answer

Il problema è che l'URL non è RESTful nell'esempio GitHub:

Preferirei vedere il URL effettivo che rappresenta esclusivamente la risorsa. Non è così difficile se ci pensi un po '.

Per essere veramente RESTful l'URI dovrebbe essere un identificatore di risorsa e nient'altro

I parametri lo rendono RPC su HTTP che è l'opposto del paradigma REST .

http://example.com/{user_id}/posts/first
http://example.com/{user_id}/posts/09/previous
http://example.com/{user_id}/posts/10
http://example.com/{user_id}/posts/11
http://example.com/{user_id}/posts/12
http://example.com/{user_id}/posts/13
http://example.com/{user_id}/posts/14
http://example.com/{user_id}/posts/15/next
http://example.com/{user_id}/posts/last

L'uso dei parametri come parte dell'identificatore è una cattiva pratica, indipendentemente da chi lo sta facendo.

http://example.com/{user_id}/posts/09/to/04/ <- previous
http://example.com/{user_id}/posts/14/to/19/ <- next

Nessun parametro e più conciso e auto-descrittivo.

Se la lista è totalmente client-side, gli identificatori dei frammenti sarebbero la scelta corretta:

Poiché i frammenti non sono mai impostati sul server su richieste, sono riferimenti totalmente client. Identificatore di frammenti è considerato una sotto-ubicazione della risorsa, che semanticamente previous e next sono sotto-ubicazioni di posts/

L'esempio specifico di RFC 5147 è applicabile qui http://example.com/document.txt#line=10,20

RFC7233 specifica l'intestazione RANGE binario. Questo è un argomento molto convincente per un'intestazione PAGINATION_RANGE personalizzata che utilizza la RFC5988 Link Header nella stessa lo spirito.

http://example.com/{user_id}/posts/first
http://example.com/{user_id}/posts/09/#previous=5
http://example.com/{user_id}/posts/10
http://example.com/{user_id}/posts/11
http://example.com/{user_id}/posts/12
http://example.com/{user_id}/posts/13
http://example.com/{user_id}/posts/14
http://example.com/{user_id}/posts/15/#next=5
http://example.com/{user_id}/posts/last

I frammenti non ricaricano la pagina ma creano cronologia:

Quindi ottieni il comportamento corretto del pulsante avanti / indietro gratis!