Search: ListIndexes operation should return a pageable collection

[heaths]

Should we make all these Get*s Pageable<T>? We can discuss it after this Preview with Bruce to get an idea of how these features might grow over time.

Originally posted by @tg-msft in #11049

[heaths]

Currently, the model returns themselves aren't pageable, but if they ever became pageable we'd be ready without a breaking change. That said, I imagine that all of these in the SearchServiceClient wouldn't yield enough results to bother making them pageable.

[heaths]

@brjohnstmsft might some of these methods ever become pageable, such that we should make the return types pageable now so these aren't breaking changes later (well, we wouldn't break the API, but would have to add overloads which isn't ideal).

[brjohnstmsft]

@heaths Probably not. The limits for these resources are documented here, and the numbers aren't high enough to justify paging.

[heaths]

@brjohnstmsft Index and Indexer limits for S3 were pretty high. If there's any chance the service would return a nextLink or something in the future, we should make it pageable now.

/cc @pakrym

[brjohnstmsft]

@heaths The max indexer count is 200; that's not high. Indexes can get up to 3000 in case of S3HD. So far that hasn't been enough to motivate us to introduce paging. We're looking at allowing more fields per index, which would increase the response size for this API, so maybe we can consider nextLink in the future. If you want to be maximally defensive against breaking changes, maybe make listing indexes pageable.

For the other resources, I would say whether you make it pageable or not should depend on how much that degrades the developer experience, because the chances of us making those APIs return nextLink is very low.

[heaths]

No, 200 isn't that high but if properties increase that still gets pretty big. Key Vault, in comparison, has pretty small pages. Making only GetIndexes pageable carries the concern about inconsistency, since enumerating a pageable method uses different code.