Dada una API web con paginación que vuelve más elementos de los que caben en la memoria en cualquier momento
HTTP GET /items?start=0&limit=10
Quiero construir un cliente fácil de utilizar Java. Un cliente de paginación es difícil de usar
PageRequest pageRequest = new PageResut(0,10);
Page<Item> page = client.findItems(page);
while( !page.isLastPage() ) {
Page<Item> nextPage = client.findItems( page.getNextPage() );
}
Ocultando el cliente paginación atrás tampoco un Iterator..
Iterator<Item> items = client.pagingItemsIterator();
// every 10 elements the iterator requests the next page behind the scenes i.e.
// the paging code of above is hidden in an iterator
items.forEachRemaining(this::dostuff);
... o una Streamhace que la API más fácil de usar
Stream<Item> items = client.pagingItemsStream();
// every 10 elements the stream requests the next page behind the scenes
// i.e. the paging code above is hidden in the stream supplier
items.forEach(this::dostuff);
Una Streames más versátil. ¿Hay algo en la modalidad de uso de una corriente para ser usado que lo hace inadecuado para este caso de uso? Me gusta:
- ¿Tiene una corriente asume todos los artículos son conocidos, en comparación con los que solicita la página siguiente en segundo plano cuando el último elemento de la corriente es exagerado?
- ¿Va en contra de las buenas prácticas corrientes, ese elemento solicitud # 11 puede fallar con un
RuntimeExceptionporque una nueva solicitud de página se realiza para obtener los elementos en la página siguiente?
Yo quería hacer esto como un comentario, pero algo era demasiado grande.
No suponga una corriente se conocen todos los artículos ...
Mire Files::lines, por ejemplo, no hay manera de saber el número exacto de líneas que se encuentran en un determinado archivo, por lo que la implementación subyacente hace que de alguna manera ... Para flujo secuencial que es fácil, para un uno paralelo - lo único que hacen es búfer hasta por lo menos 1024las líneas están tamponada (+ 1,024 en la siguiente memoria intermedia y así sucesivamente). Así que sí, una implementación corriente, sin un tamaño conocido es absolutamente posible, incluso si ese tamaño puede cambiar dinámicamente - aunque esto trae un montón de otros problemas de la OMI.
¿Va en contra de las buenas prácticas corrientes, ese elemento solicitud # 11 puede fallar con un RuntimeException porque una nueva solicitud de página se realiza para obtener los elementos en la página siguiente?
No muy seguro de entender esto por completo, pero parece que usted se refiere a múltiples peticiones simultáneas a los mismos datos. Si es así, esto no es normal para mí como para los flujos mucho ya que no es normal que solo el PageRequest; después de todo lo que acaba de leer los datos - si es que no existe, devuelve una lista vacía o lista parcial o lo que sea, pero no una excepción. Si el subyacente PageRequesttiros que, tratarla de la envoltura que va a tener de todos modos.
Sólo aviso que por lo general se puede transformar muy fácilmente de una Iterator -> Streamy de Stream -> Iteratorser necesario. Aun así, me gustaría seguir con un Streamenfoque si puede ponerlo en práctica.