Ostatnio przeprowadziłem obszerne badania nad tym i innymi pytaniami związanymi ze stronicowaniem REST i pomyślałem, że dodanie niektórych moich ustaleń tutaj jest konstruktywne. Rozszerzam nieco pytanie, aby uwzględnić przemyślenia na temat stronicowania, a także liczbę, ponieważ są one ściśle powiązane.
Nagłówki
Metadane stronicowania są dołączane do odpowiedzi w postaci nagłówków odpowiedzi. Dużą zaletą tego podejścia jest to, że sam ładunek odpowiedzi jest po prostu tym, o co prosił żądający danych. Ułatwienie przetwarzania odpowiedzi klientom, którzy nie są zainteresowani informacjami dotyczącymi stronicowania.
Istnieje wiele (standardowych i niestandardowych) nagłówków używanych w środowisku naturalnym do zwracania informacji związanych ze stronicowaniem, w tym całkowitej liczby.
Całkowita liczba X
X-Total-Count: 234
Jest to używane w niektórych interfejsach API , które znalazłem na wolności. Istnieją również pakiety NPM do dodania obsługi tego nagłówka np. Do Loopback. Niektóre artykuły zalecają również ustawienie tego nagłówka.
Jest często używany w połączeniu z Linknagłówkiem, co jest całkiem dobrym rozwiązaniem do stronicowania, ale brakuje mu informacji o całkowitej liczbie.
Połączyć
Link: </TheBook/chapter2>;
rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
</TheBook/chapter4>;
rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel
Czuję, czytając wiele na ten temat, że ogólny konsensus jest użycie Linknagłówka , aby zapewnić stronicowania linki do klientów korzystających rel=next, rel=previousitd. Problemem jest to, że brakuje informacji o tym, jak wiele łącznych zapisów istnieją, co jest dlaczego wiele interfejsów API łączy to z X-Total-Countnagłówkiem.
Alternatywnie, niektóre API, np. Standard JsonApi , używają Linkformatu, ale dodają informacje w kopercie odpowiedzi zamiast do nagłówka. Upraszcza to dostęp do metadanych (i tworzy miejsce do dodawania informacji o całkowitym zliczeniu) kosztem rosnącej złożoności dostępu do samych danych (poprzez dodanie koperty).
Zakres zawartości
Content-Range: items 0-49/234
Promowany przez artykuł na blogu zatytułowany Nagłówek zakresu, wybieram Cię (do paginacji)! . Autor przedstawia argumenty przemawiające za używaniem nagłówków Rangei Content-Rangedo paginacji. Kiedy uważnie zapoznać się z RFC na te nagłówki, okazuje się, że rozszerzenie ich znaczenie poza zakresy bajtów faktycznie zablokowane przez RFC i jest wyraźnie dozwolone. Użyty w kontekście itemszamiast bytes, nagłówek Range w rzeczywistości umożliwia nam zarówno zażądanie określonego zakresu elementów, jak i wskazanie, do jakiego zakresu całkowitego wyniku odnoszą się elementy odpowiedzi. Ten nagłówek daje również świetny sposób na pokazanie całkowitej liczby. I jest to prawdziwy standard, który przeważnie odwzorowuje stronicowanie jeden do jednego. Jest również używany na wolności .
Koperta
Wiele interfejsów API, w tym ten z naszej ulubionej witryny z pytaniami i odpowiedziami, wykorzystuje kopertę , otokę wokół danych, która służy do dodawania metainformacji o danych. Ponadto standardy OData i JsonApi używają obwiedni odpowiedzi.
Dużą wadą tego (imho) jest to, że przetwarzanie danych odpowiedzi staje się bardziej złożone, ponieważ rzeczywiste dane muszą znajdować się gdzieś w kopercie. Istnieje również wiele różnych formatów tej koperty i musisz użyć właściwego. Jest to wymowne, że obwiednie odpowiedzi z OData i JsonApi są bardzo różne, z mieszaniem OData w metadanych w wielu punktach odpowiedzi.
Oddzielny punkt końcowy
Myślę, że zostało to wystarczająco uwzględnione w innych odpowiedziach. Nie badałem tak dużo, ponieważ zgadzam się z komentarzami, że jest to mylące, ponieważ masz teraz wiele typów punktów końcowych. Myślę, że najładniej jest, jeśli każdy punkt końcowy reprezentuje (zbiór) zasobów.
Dalsze przemyślenia
Musimy nie tylko przekazywać metadane stronicowania związane z odpowiedzią, ale także pozwolić klientowi zażądać określonych stron / zakresów. Warto również przyjrzeć się temu aspektowi, aby uzyskać spójne rozwiązanie. Tutaj również możemy użyć nagłówków ( Rangenagłówek wydaje się bardzo odpowiedni) lub innych mechanizmów, takich jak parametry zapytania. Niektórzy ludzie opowiadają traktowanie stron wyników w postaci oddzielnych środków, które mogą mieć sens w niektórych przypadkach zastosowania (np /books/231/pages/52. Skończyło się wybierając dziką gamę najczęściej używanych parametrów żądania takich jak pagesize, page[size]i limitetc oprócz wspierania Rangenagłówek (i jak żądanie parametru także).