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

Seltsam, dass niemand darauf hingewiesen hat, dass bei Option 3 die Parameter in einer bestimmten Reihenfolge stehen. http//application/products/Date/Descending/Name/Ascending/page/2 と http//application/products/Name/Aufsteigend/Datum/Absteigend/page/2

verweisen auf dieselbe Ressource, haben aber völlig unterschiedliche URLs.

Option 1 erscheint mir am akzeptabelsten, da sie eine klare Trennung zwischen "Was ich will" y "Wie ich will" (Es steht sogar ein Fragezeichen dazwischen, lol). Full-Page-Caching kann mit voller URL implementiert werden (Alle Optionen werden von dem gleichen Problem sowieso leiden).

Beim Parameter-in-URL-Ansatz ist der einzige Vorteil eine saubere URL. Allerdings muss man sich etwas einfallen lassen, um Parameter zu kodieren und verlustfrei zu dekodieren. Natürlich können Sie mit URLencode/decode gehen, aber es wird Urls wieder hässlich machen :)

Answer 2

Auf der Suche nach bewährten Verfahren bin ich auf diese Website gestoßen:

http://www.restapitutorial.com

Auf der Ressourcenseite gibt es einen Link zum Herunterladen einer .pdf-Datei, die alle vom Autor vorgeschlagenen REST-Best Practices enthält. Darin gibt es unter anderem einen Abschnitt über die Paginierung.

Der Autor schlägt vor, sowohl die Verwendung eines Range-Headers als auch die Verwendung von Query-String-Parametern zu unterstützen.

Anfrage

Beispiel für einen HTTP-Header:

Range: items=0-24

Beispiel für Abfrage-String-Parameter:

GET http://api.example.com/resources?offset=0&limit=25

Où Versatz ist die Nummer des Anfangspostens und Grenze ist die maximale Anzahl der zurückzugebenden Elemente.

Antwort

Die Antwort sollte einen Content-Range-Header enthalten, der angibt, wie viele Elemente zurückgegeben werden und wie viele Elemente insgesamt noch abgerufen werden müssen

Beispiele für HTTP-Header:

Content-Range: items 0-24/66

Content-Range: items 40-65/*

In der .pdf-Datei finden Sie einige weitere Vorschläge für spezielle Fälle.

Answer 3

Ich würde es vorziehen, die Abfrageparameter offset und limit zu verwenden.

Versatz Index für das Element in der Sammlung.

Grenze : für die Anzahl der Artikel.

Der Kunde kann den Offset einfach wie folgt aktualisieren

offset = offset + limit

für die nächste Seite.

Der Pfad wird als Ressourcenkennung betrachtet. Und eine Seite ist keine Ressource, sondern eine Teilmenge der Ressourcensammlung. Da es sich bei der Paginierung in der Regel um eine GET-Anfrage handelt, sind Abfrageparameter für die Paginierung besser geeignet als Kopfzeilen.

Referenz: https://metamug.com/article/rest-api-developers-dilemma.html#Requesting-the-next-page

Answer 4

Ich verwende derzeit ein ähnliches Schema in meinen ASP.NET MVC-Anwendungen:

z.B.. http://application/products/by-date/page/2

konkret heißt es: http://application/products/Date/Ascending/3

Ich bin jedoch nicht wirklich zufrieden damit, dass die Informationen auf diese Weise in die Route eingefügt werden.

Die Liste der Elemente (in diesem Fall Produkte) ist veränderlich, d. h. wenn jemand das nächste Mal zu einer URL mit Paging- und Sortierparametern zurückkehrt, können sich die Ergebnisse, die er erhält, geändert haben. Daher ist die Idee von http://application/products/Date/Ascending/3 da eine eindeutige URL, die auf eine definierte, unveränderliche Gruppe von Produkten verweist, verloren geht.

Answer 5

Ich neige dazu, slf zuzustimmen, dass "Seite" nicht wirklich eine Ressource ist. Andererseits ist Option 3 sauberer, leichter zu lesen und kann vom Benutzer leichter erraten und bei Bedarf sogar abgetippt werden. Ich bin hin- und hergerissen zwischen Option 1 und 3, sehe aber keinen Grund, nicht Option 3 zu verwenden.

Ein Nachteil der Verwendung versteckter Parameter anstelle von Abfragezeichenfolgen oder URL-Segmenten besteht darin, dass der Benutzer keine Lesezeichen setzen oder einen direkten Link zu einer bestimmten Seite erstellen kann, auch wenn sie schön aussehen. Das kann je nach Anwendung ein Problem sein oder auch nicht, aber man sollte es einfach im Hinterkopf behalten.