Paginierung in einer REST-Webanwendung

Question

Dies ist eine allgemeinere Umformulierung von diese Frage (mit der Eliminierung der Rails-spezifischen Teile)

Ich bin nicht sicher, wie Paginierung auf eine Ressource in einer RESTful-Webanwendung zu implementieren. Angenommen, ich habe eine Ressource namens products Welcher der folgenden Ansätze ist Ihrer Meinung nach der beste und warum?

1. Nur Abfragezeichenfolgen verwenden

z. B. http://application/products?page=2&sort_by=date&sort_how=asc
Das Problem dabei ist, dass ich kein Full Page Caching verwenden kann und dass die URL nicht sehr sauber und leicht zu merken ist.

2. Verwendung von Seiten als Ressourcen und Abfragezeichenfolgen für die Sortierung

z. B. http://application/products/page/2?sort_by=date&sort_how=asc
In diesem Fall ist das Problem, das wir sehen, dass http://application/products/pages/1 ist keine eindeutige Ressource, da die Verwendung von sort_by=price kann zu einem völlig anderen Ergebnis führen と Ich kann das Seiten-Caching immer noch nicht nutzen.

3. Verwendung von Seiten als Ressourcen und eines URL-Segments für die Sortierung

z. B. http://application/products/by-date/page/2
Ich persönlich sehe kein Problem darin, diese Methode zu verwenden, aber jemand hat mich gewarnt, dass dies kein guter Weg ist (er hat keinen Grund genannt, wenn Sie also wissen warum es nicht empfohlen wird, lassen Sie es mich bitte wissen)

Jede Vorschläge, Meinungen und Kritiken sind mehr als willkommen. Danke!

Answer 1

Ich stimme mit Fionn überein, aber ich gehe noch einen Schritt weiter und sage, dass die Seite für mich no eine Ressource, es ist eine Eigenschaft der Anfrage. Das macht mich wählte Option 1 Abfragezeichenfolge nur. Es fühlt sich einfach richtig an. Ich mag wirklich, wie die Twitter-API ist ruhig strukturiert. Nicht zu einfach, nicht zu kompliziert, gut dokumentiert. Im Guten wie im Schlechten ist es mein "Go-to"-Design, wenn ich unschlüssig bin, ob ich etwas auf die eine oder andere Weise machen soll.

Answer 2

Ich denke, das Problem mit Version 3 ist eher ein Problem des Blickwinkels - sehen Sie die Seite als Ressource oder die Produkte auf der Seite.

Wenn Sie die Seite als Ressource betrachten, ist dies eine sehr gute Lösung, da die Abfrage nach Seite 2 immer Seite 2 ergibt.

Wenn Sie aber die Produkte auf der Seite als Ressource sehen, haben Sie das Problem, dass sich die Produkte auf Seite 2 ändern können (alte Produkte gelöscht oder was auch immer), in diesem Fall gibt der URI nicht immer die gleiche(n) Ressource(n) zurück.

Ein Kunde speichert z. B. einen Link zur Produktlistenseite X. Wenn der Link das nächste Mal geöffnet wird, befindet sich das betreffende Produkt möglicherweise nicht mehr auf Seite X.

Answer 3

HTTP hat einen großen Range-Header, der auch für die Paginierung geeignet ist. Sie können senden

Range: pages=1

nur die erste Seite zu haben. Das könnte Sie dazu zwingen, neu zu überdenken, was eine Seite ist. Vielleicht möchte der Kunde einen anderen Bereich von Artikeln. Die Bereichsüberschrift dient auch dazu, eine Reihenfolge zu deklarieren:

Range: products-by-date=2009_03_27-

um alle Produkte zu erhalten, die neuer sind als dieses Datum oder

Range: products-by-date=0-2009_11_30

um alle Produkte zu erhalten, die älter als dieses Datum sind. 0' ist wahrscheinlich nicht die beste Lösung, aber RFC scheint etwas für den Beginn eines Bereichs zu wollen. Möglicherweise sind HTTP-Parser im Einsatz, die units=-range_end nicht parsen würden.

Wenn Header keine (akzeptable) Option ist, vermute ich, dass die erste Lösung (alle in Abfragezeichenfolge) eine Möglichkeit ist, mit Seiten umzugehen. Aber bitte, normalisieren Sie die Abfrage-Strings (sortieren Sie (Schlüssel=Wert) Paare in alphabetischer Reihenfolge). Dies löst das "?a=1&b=x" und "?b=x&a=1" Differenzierungsproblem.

Answer 4

Option 1 scheint die beste zu sein, sofern Ihre Anwendung die Paginierung als eine Technik zur Erzeugung einer anderen Ansicht derselben Ressource betrachtet.

Davon abgesehen ist das URL-Schema relativ unbedeutend. Wenn Sie Ihre Anwendung so gestalten, dass sie hypertextgesteuert (wie es alle REST-Anwendungen per Definition sein müssen), dann wird Ihr Client keine URIs selbst konstruieren. Stattdessen gibt Ihre Anwendung die Links an den Client weiter und der Client folgt ihnen.

Eine Art von Link, die Ihr Kunde anbieten kann, ist ein Paginierungslink.

Der angenehme Nebeneffekt von all dem ist, dass, selbst wenn Sie Ihre Meinung über die URI-Struktur der Paginierung ändern und nächste Woche etwas völlig anderes implementieren, Ihre Kunden ohne jegliche Änderung weiterarbeiten können.

Answer 5

Ich habe immer den Stil von Option 1 verwendet. Die Zwischenspeicherung war kein Problem, da sich die Daten in meinem Fall ohnehin häufig ändern. Wenn Sie zulassen, dass die Größe der Seite konfigurierbar ist, können die Daten wiederum nicht zwischengespeichert werden.

Ich finde die Url nicht schwer zu merken oder unsauber. Für mich ist dies eine gute Verwendung von Abfrageparametern. Die Ressource ist eindeutig eine Liste von Produkten, und die Abfrageparameter geben nur an, wie die Liste angezeigt werden soll - sortiert und auf welcher Seite.