kbendick commented on a change in pull request #3561: URL: https://github.com/apache/iceberg/pull/3561#discussion_r757705583
########## File path: rest_docs/rest-catalog-v0.1-SNAPSHOT.md ########## @@ -0,0 +1,1810 @@ +--- +title: Apache Iceberg REST Catalog API v1.0.0 +language_tabs: + - shell: Shell + - java: Java +language_clients: + - shell: "" + - java: "" +toc_footers: [] +includes: [] +search: true +highlight_theme: darkula +headingLevel: 2 + +--- + +<!-- Generator: Widdershins v4.0.1 --> + +<h1 id="apache-iceberg-rest-catalog-api">Apache Iceberg REST Catalog API v1.0.0</h1> + +> Scroll down for code samples, example requests and responses. Select a language for code samples from the tabs above or the mobile navigation menu. + +Defines the specification for the first version of the REST Catalog API. Implementations should support both Iceberg table specs v1 and v2, with priority given to v2. + +Base URLs: + +* <a href="http://127.0.0.1:1080";>http://127.0.0.1:1080</a> + +License: <a href="https://www.apache.org/licenses/LICENSE-2.0.html";>Apache 2.0</a> + +# Authentication + +- HTTP Authentication, scheme: bearer + +<h1 id="apache-iceberg-rest-catalog-api-configuration-api">Configuration API</h1> + +## getConfig + +<a id="opIdgetConfig"></a> + +> Code samples + +```shell +# You can also use wget +curl -X GET http://127.0.0.1:1080/v1/config \ + -H 'Accept: application/json' \ + -H 'Authorization: Bearer {access-token}' + +``` + +```java +URL obj = new URL("http://127.0.0.1:1080/v1/config";); +HttpURLConnection con = (HttpURLConnection) obj.openConnection(); +con.setRequestMethod("GET"); +int responseCode = con.getResponseCode(); +BufferedReader in = new BufferedReader( + new InputStreamReader(con.getInputStream())); +String inputLine; +StringBuffer response = new StringBuffer(); +while ((inputLine = in.readLine()) != null) { + response.append(inputLine); +} +in.close(); +System.out.println(response.toString()); + +``` + +`GET /v1/config` + +*List all catalog configuration settings* + +All REST catalogs will be initialized by calling this route. This route will return at least the minimum necessary metadata to initialize the catalog. Optionally, it can also include server-side specific overrides. For example, it might also include information used to initialize this catalog such as the details of the Http connection pooling, etc. This route might also advertise information about operations that are not implemented so that the catalog can eagerly throw or go about another way of performing the desired action. Review comment: Certainly I don't mind clarifying, thank you for asking. I will also update the description. :D So connection pooling is admittedly a bad example, as you're right that it is really application specific and best placed with the application. Though admittedly, even that some people might want to be able to control. > Or is this meant more for the Spark (or equivalent) catalog settings? Ideally it's meant for that first and foremost. Having worked in managing a large number of people's jobs, where often times they didn't care about the underlying architecture or want to have to deal with it), there are some configs it's nice to be able to inject oneself vs having to get all of your users to put them there. So things like Spark configs can definitely fit into that scope. > Or is the idea that the http client would get re-configured once this call is made. Outside of Spark configs, I'm not opposed to the idea of "re-configuring", though I wouldn't necessarily re-configure but have a thin single use HTTP client that is started on the driver or equivalent for one initial setup, that is then closed and the real HTTP client takes over. Then, the REST catalog can be fully `initialize`d itself off of that. So mostly, yes Spark configs or even Iceberg specific configs that are somewhat terse and a pain for users but a good idea in a particular environment as a default. So probably leaving it as a thin client that is closed as an init type situation might make sense to allow the catalog and the HTTP client to be more fully configured. Off the top of my head, the user might have an authentication token and a base address, but this endpoint could then provide them the correct API endpoint / host for their specific environment - e.g. maybe a dev vs prod type set up (as one example). In which case this endpoint would need to be called so that the full http client can be configured. I'm open to both, but I was admittedly more thinking like engine-catalog specific configurations, like Flink requires catalogs to have known configs and this might be one way to get them somewhat more dynamically than just adding them all to the source code one by one which might not make sense in all scenarios (think of the number of s3a configs there are even). -- 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]
