2010-01-06 10 views
5

wir haben eine Suche/list-Ressource:REST api Paginierung: make Seitengröße ein Parameter (konfigurierbar von außen)

http://xxxx/users/?page=1

Intern werden die Seitengröße ist statisch und gibt 20 Elemente. Der Benutzer kann vorwärts gehen, indem er die Seitenzahl erhöht. Aber flexibler sein wir jetzt auch denken die Größe einer Seite zu belichten:

http://xxxx/users/?page=1&size=20

Als solches ist dies flexibel wie der Client jetzt Netzwerk-Anrufe vs. Größe der Antwort entscheiden kann, bei der Suche. Natürlich hat dies den Nachteil, dass die Server-Fest entweder zufällig getroffen werden könnte oder maliciosly absichtlich: http://xxxx/users/?page=1&size=1000000

Für Robustheit die Lösung sein könnte eine Obergrenze von Seitengröße (zB 100), und wenn sie überschritten werden konfigurieren entweder eine Fehlerantwort oder eine HTTP-Umleitung zu der URL mit dem höchstmöglichen Seitengrößenparameter.

Was denkst du?

Antwort

8

Persönlich würde ich einfach eine maximale Seitengröße dokumentieren, und alles, was größer ist als das wird einfach als das Maximum behandelt.

3

Verwalten von Zugriff auf Ressourcen ist immer eine gute Idee aka Schutz außerhalb Schnittstellen: mit anderen Worten, setzen Sie eine vernünftige Grenze.

Die Weiterleitung kann eine gute Idee sein, wenn es um die Entwicklungszeit geht, d. H. Wenn der Benutzer der API mit dem Dienst vertraut wird, aber außerhalb dieser Situation bezweifle ich, dass es einen Wert gibt.

Stellen Sie sicher, dass die Parameter in jeder Hinsicht gut dokumentiert sind.

1

Haben Sie dies getestet, um zu sehen, ob es sogar ein Problem ist? Wenn ein Benutzer nach einer Seitengröße von einer Million fragt, führt dies wirklich dazu, dass alle anderen Anfragen gestoppt/verlangsamt werden? Wenn das der Fall ist, schaue ich mir zuerst die zugrunde liegende Architektur an. Aber wenn das am Ende ein Problem ist, dann glaube ich nicht, dass das Setzen einer harten Grenze für die Seitengröße schlecht ist.

Frage: Wenn ich Benutzer GETs die URI http://xxx/user?page=1 hat die Antwort einen Link auf die nächste Seite? vorherige Seite? Wenn nicht, dann ist es nicht wirklich RESTful.

+0

Ich bin mehr besorgt, dass unnötige hohe Nutzlast erzeugt wird und Bandbreite verschwendet wird. Sicher, die Anwendung wird nicht abstürzen, aber es wird unnötige Belastung auf das Such-Backend und auf die xml/json-Antwort-Gebäude verursachen. Aus meiner Sicht ist das Senden von size = 1000000 ziemlich seltsam und ist entweder zufällig oder bösartig. sicher, Paging-Links sind enthalten :) –

+1

Verstanden - aber für jemanden, der Data Mining oder andere Aktionen, die einen großen Datensatz benötigen, ich kann es passiert sehen. Ehrlich gesagt würde ich eine schlechte Anfrage (400) werfen, mit einer Fehlermeldung, die die maximale Seitengröße angibt. Die Rückgabe einiger serverdefinierter Items sieht für den Benutzer so aus, als ob er nach 100000 gefragt hätte, aber 200, was wahrscheinlich bedeutet, dass nur 200 Items gefunden werden können. – Gandalf

+0

Wenn Sie die nächsten/vorherigen Paging-Links zurücksenden, sollte klar sein, dass mehr Daten vorhanden sind. – Nate