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: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org