Problem z paginacją w projekcie API RESTful

Question

Projektuję interfejs API RESTful dla aplikacji mobilnej, nad którą pracuję. Mój problem dotyczy dużych kolekcji zawierających wiele przedmiotów. Rozumiem, że dobrą praktyką jest umieszczanie dużej liczby wyników w kolekcji.

Czytałem Facebook Graph API doc (https://developers.facebook.com/docs/graph-api/using-graph-api/v2.2), Twitter kursory doc (https://dev.twitter.com/overview/api/cursoring), GitHub API doc (https://developer.github.com/v3/) i tego postu (API pagination best practices).

Weź pod uwagę przykładową kolekcję /resources w moim interfejsie API zawierającą 100 elementów o nazwie resource1 na resource100 i posortowanych malejąco. Jest to odpowiedź otrzymasz na żądanie GET (GET http://api.path.com/resources?limit=5):

{ 
    "_links": { 
     "self": { "href": "/resources?limit=5&page=1" }, 
     "last": { "href": "/resources?limit=5&page=7" }, 
     "next": { "href": "/resources?limit=5&page=2" } 
    }, 

    "_embedded": { 
     "records": [ 
      { resource 100 }, 
      { resource 99 }, 
      { resource 98 }, 
      { resource 97 }, 
      { resource 96 } 
     ] 
    } 
} 

Teraz mój problem jest scenariusz tak:

1- I GET /resources z powyższych treści.

2- Następnie coś jest dodawane do kolekcji zasobów (np. Inne urządzenie dodaje nowy zasób dla tego konta). Teraz mam 101 zasobów.

3- I GET /resources?limit=5&page=2 jak sugeruje wstępna odpowiedź będzie zawierać następną stronę moich wyników. Odpowiedź byłaby tak:

{ 
    "_links": { 
     "self": { "href": "/history?page=2&limit=5" }, 
     "last": { "href": "/history?page=7&limit=5" }, 
     "next": { "href": "/history?page=3&limit=5" } 
    }, 

    "_embedded": { 
     "records": [ 
      { resource 96 }, 
      { resource 95 }, 
      { resource 94 }, 
      { resource 93 }, 
      { resource 92 } 
     ] 
    } 
} 

Jak widać resource 96 powtarza się w obu stron (lub podobny problem może się zdarzyć, jeśli zasób zostanie usunięty w punkcie 2, w tym przypadku jeden zasób zostaną utracone).

Ponieważ chcę używać tego w aplikacji mobilnej i na jednej liście, muszę dołączyć zasoby każdego wywołania API do tego przed nim, więc mogę mieć pełną listę. Ale to jest kłopotliwe. Daj mi znać, jeśli masz sugestię. Z góry dziękuję.

P.S: Rozważałem znacznik czasu, jak ciągi zapytań zamiast stronicowania opartego na kursorach, ale to spowoduje problemy gdzie indziej dla mnie. (daj mi znać, jeśli potrzebujesz więcej informacji na ten temat.)

Answer 1

Dlaczego po prostu nie utrzymywać zestawu widzialnych zasobów?

Następnie podczas przetwarzania każdej odpowiedzi można sprawdzić, czy zasób jest już prezentowany.

Answer 2

Właśnie zaimplementowaliśmy coś podobnego do tej aplikacji mobilnej za pośrednictwem interfejsu API REST. Aplikacja mobilna przekazała dodatkowy parametr zapytania, który reprezentuje znacznik czasu, w którym elementy na stronie powinny zostać "zamrożone".

Więc twój pierwszy wniosek będzie wyglądać GET /resources?limit=5&page=1&from=2015-01-25T05:10:31.000Z a następnie drugi wniosek strony (jakiś czas później) by zwiększyć liczbę stron, ale zachować ten sam znacznik czasu: GET /resources?limit=5&page=2&from=2015-01-25T05:10:31.000Z

Daje również aplikację mobilną kontrolę, jeśli chce aby odróżnić stronę "miękką" (zachowując znacznik czasu żądania strony 1) od strony "twardego odświeżania" (resetując znacznik czasu do bieżącego czasu).