danielcweeks commented on code in PR #9660:
URL: https://github.com/apache/iceberg/pull/9660#discussion_r1484854975
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1482,6 +1490,38 @@ components:
explode: false
example: "vended-credentials,remote-signing"
+ page-token:
+ name: pageToken
+ in: query
+ description:
+ A unique token which allows clients to make use of pagination by
signaling to the service that they would
+ prefer requests to be paginated based on the number of items specified
by pageSize.
+
+ New Clients always start the request by sending a required empty
pageToken e.g. GET /tables?pageToken
+ Servers supporting pagination would recognize pagination is requested
due to the presence of the pageToken
+ and honor the contracts specified above by returning a non-empty next
pageToken
+ if there are more results available, or an empty next pageToken
indicating no more results.
+ Servers that are non-pagination aware will ignore the token and return
all results as they previously did.
+
+ Old clients should not be specifying the new parameters
+ For servers that support pagination, they would notice the lack of the
pageToken
+ in the query string and return all results at once (mimicking existing
behavior).
+ For servers not supporting pagination, this is the current state and
they would return all values at once.
+ required: false
+ allowEmptyValue: true
+ schema:
+ type: string
+
+ page-size:
+ name: pageSize
+ in: query
+ description:
+ An upper bound on the number of results to return on the next page.
Review Comment:
I think we need to state that this is a requested result size and that it
may not be honored by the server. The issue is that a client will not know
whether the server supports pagination and it may not get back the number of
results indicated in the page size. For example if you requests 100 results,
but the server does not support pagination, you may get 1000 results back.
Therefore, this cannot be a guaranteed upper-bound.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
