practices - Problema de paginación en el diseño RESTful API

rest api routes

Question

Estoy diseñando una API RESTful para una aplicación móvil en la que estoy trabajando. Mi problema es con grandes colecciones que contienen muchos elementos. Entiendo que una buena práctica es paginar una gran cantidad de resultados en una colección.

He leído el documento de la API de Graph de Facebook ( https://developers.facebook.com/docs/graph-api/using-graph-api/v2.2 ), cursores de Twitter doc ( https://dev.twitter.com/ descripción general / api / cursoring ), GitHub API doc ( https://developer.github.com/v3/ ) y esta publicación ( API mejores prácticas de paginación ).

Considere un ejemplo de colección /resources en mi API que contiene 100 elementos denominados resource1 a resource100 y ordenados descendentemente. Esta es la respuesta que recibirá en una solicitud GET http://api.path.com/resources?limit=5 ( 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 }
]
}
}

Ahora mi problema es un escenario como este:

1- GET /resources con los contenidos anteriores.

2- Después de eso, se agrega algo a la colección de recursos (digamos que otro dispositivo agrega un nuevo recurso para esta cuenta). Entonces ahora tengo 101 recursos.

3- I GET /resources?limit=5&page=2 como sugiere la respuesta inicial contendrá la página siguiente de mis resultados. La respuesta sería así:

{
"_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 }
]
}
}

Como puede ver, el resource 96 se repite en ambas páginas (O puede haber un problema similar si se elimina un recurso en el paso 2, en ese caso se perderá un recurso).

Como quiero usar esto en una aplicación móvil y en una lista, debo agregar los recursos de cada llamada API a la anterior para poder tener una lista completa. Pero esto es preocupante. Por favor, hágame saber si tiene alguna sugerencia. Gracias de antemano.

PD: He considerado la marca de tiempo como cadenas de consulta en lugar de la paginación basada en cursor, pero eso creará problemas en otro lugar para mí. (Avíseme si necesita más información al respecto).

Answer 1

¿Por qué no mantener un conjunto de recursos vistos?

Luego, cuando procesa cada respuesta, puede verificar si el recurso ya se está presentando.

Answer 2

Acabamos de implementar algo similar a esto para una aplicación móvil a través de una API REST. La aplicación móvil pasó un parámetro de consulta adicional que representa una marca de tiempo en la que los elementos de la página deben estar "congelados".

Por lo tanto, su primera solicitud se vería como GET /resources?limit=5&page=1&from=2015-01-25T05:10:31.000Z y luego la segunda solicitud de la página (algún tiempo después) incrementaría el número de páginas pero mantendría la misma marca de tiempo: GET /resources?limit=5&page=2&from=2015-01-25T05:10:31.000Z

Esto también le da al control de la aplicación móvil si quiere diferenciar una página "suave" (conservando la marca de tiempo de la solicitud de la página 1) de una página "actualización" (reiniciando la marca de tiempo a la hora actual).