java - 带分页的 API 的 Stream 与 Iterator

Question

给定一个带分页的 web API，该 API 返回更多的项目，超过了内存在任何时候都可以容纳的项目

HTTP GET /items?start=0&limit=10

我想构建一个易于使用的 Java 客户端。分页客户端很难用

PageRequest pageRequest = new PageResut(0,10);
Page<Item> page = client.findItems(page);
while( !page.isLastPage() ) {
   Page<Item> nextPage = client.findItems( page.getNextPage() );
}

将分页客户端隐藏在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);

... 或 Stream 使 API 更易于使用

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);

Stream 更通用。流的使用方式是否有任何不适合此用例的地方？喜欢:

• 与在获取流中的最后一个项目时在幕后请求下一页相比，流是否假设所有项目都是已知的？
• 这是否违反了流的良好做法，因为执行新页面请求以获取下一页中的项目，请求项目 #11 可能会失败并返回 RuntimeException？

Answer 1

我想把它作为评论，但有点太大了。

Does a stream assume all items are known...

例如，查看 Files::lines，没有办法知道某个文件中的确切行数，因此底层实现以某种方式做到了......对于顺序流这很容易，对于并行的 - 他们所做的就是缓冲，直到至少 1024 行被缓冲(+ 1024 在下一个缓冲区中等等)。所以，是的，没有已知大小的流实现是绝对可能的，即使该大小可以动态更改——尽管这也带来了很多其他问题 IMO。

Is it against good practices of streams, that request item #11 can fail with a RuntimeException because a new page request is performed to get items in the next page?

不太确定我是否完全理解这一点，但您似乎担心对同一数据的多个同时请求。如果是这样，这对我来说对于流来说是不正常的，就像对于 just PageRequest 来说也是不正常的；毕竟你只是读取数据 - 如果它不存在，返回一个空列表或部分列表或其他任何东西，但不要抛出异常。如果底层 PageRequest 抛出它，请在您将拥有的包装器中处理它。

请注意，如果需要，通常您可以很容易地从 Iterator -> Stream 和 Stream -> Iterator 进行转换。即便如此，如果可以实现的话，我还是会坚持使用 Stream 方法。