rdblue commented on a change in pull request #3561:
URL: https://github.com/apache/iceberg/pull/3561#discussion_r753883555



##########
File path: rest_docs/rest-catalog-open-api-v0.1.yaml
##########
@@ -0,0 +1,763 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+#
+
+---
+openapi: 3.0.3
+info:
+  title: Apache Iceberg REST Catalog API
+  license:
+    name: Apache 2.0
+    url: https://www.apache.org/licenses/LICENSE-2.0.html
+  version: 1.0.0
+  description:
+    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.
+servers:
+  - url: http://127.0.0.1:1080
+    description: URL Used for Mock-Server Unit Tests
+# All routes are currently configured using an Authorization header.
+security:
+- BearerAuth: []
+paths:
+  /v1/config:
+    get:
+      tags:
+      - Configuration API
+      summary: List all catalog configuration settings
+      operationId: getConfig
+      description:
+        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.
+      responses:
+        default:
+          description: Server-Specific Configuration Overrides
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/IcebergConfiguration'
+        "400":
+          description: Unknown Error
+        "401":
+          description: Invalid credentials provided
+  # This might be optional for now as it's not really supported in
+  # the normal Catalog spec, but we might want to include it for
+  # convenience.
+  /v1/catalogs/{catalog}:
+    parameters:
+      - name: catalog
+        in: path
+        required: true
+        description: Name of the catalog being configured
+        schema:
+          type: string
+          minLength: 1
+    post:
+      tags:
+         - Configuration API
+      summary: Persist catalog specific configuration, which can be retrieved
+        for later use.
+      operationId: postConfig
+      description:
+        Persist some catalog specific configurations, which will be returned 
by \
+        calls to /v1/config in the future. This is basically all of the data \
+        that would go into the Catalog's `initialize` call.
+      # TODO - Make this into a CatalogConfiguration
+      requestBody:
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/Catalog'
+        required: true
+      responses:
+        '200':
+          description: OK
+        '401':
+          description: Unauthorized / Invalid Credentials Provided
+
+  # Could also consider /v1/tables/{identifier}

Review comment:
       Try to avoid leaving in comments like this. If there's a design choice 
like this one, then try to come up with a reason why you think one way or 
another is the best option and go with that. If it's a hard choice, then you 
can always reach out to the community to discuss it. And if it's a 50/50 call, 
then it's probably best just to choose one and go with it.




-- 
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]

Reply via email to