Page Iterator -Allow passing request options#34
Conversation
nikithauc
requested review from
MIchaelMainer,
baywet,
ddyett,
peombwa and
zengin
tasks/PageIteratorTask.md
Outdated
| - Dereference the next page link, when each of the the entities of the current page have been passed to the callback. | ||
|
|
||
| 1. Accept any collection of entities that contains a link to a next page | ||
| 2. Accept a callback function that will be called for each entity in each page of the collection. The callback function should provide a way to indicate to the iterator to stop iterating. |
There was a problem hiding this comment.
We should specify a requirement that the iterator should be resumeable. I think it is currently, but we should make it explicit.
There was a problem hiding this comment.
When can the iterator be paused and resumed?
There was a problem hiding this comment.
I think an example may work best to illustrate.
A customer performs a search that results in a paged result set. They get the first page, inspect the results in the UI, and then decides that they want to see the next page. They select the next page icon, and inspect the next page of results in the UI. The user is driving the use of the API. We will want to pause paging until the user wants to see the next page (resume) as it may not make sense to see another page until after they have reviewed the first page.
Another example of resumability is with delta query. The client reads all of the pages and on the last page, receive a delta query, which stored for later use. At some indeterminate point in the future, the delta query is used to resume paging to get the next set of paged changes.
There was a problem hiding this comment.
Specified the requirement that the iterator should be resumeable.
3 participants
No description provided.