kbendick commented on a change in pull request #3561: URL: https://github.com/apache/iceberg/pull/3561#discussion_r768116334
########## File path: rest_docs/rest-catalog-open-api-v0.1.yaml ########## @@ -0,0 +1,633 @@ +# +# 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: https://{host}:{port}/{basePath} + variables: + host: + description: The host address for the specified server + default: localhost + port: + description: The port used when addressing the host + default: "443" + basePath: + default: v1 + - url: http://127.0.0.1:1080/v1 + description: URL Used for Mock-Server Unit Tests +# All routes are currently configured using an Authorization header. +security: + - BearerAuth: [] +paths: + /config: + get: + tags: + - Configuration API + summary: List all catalog configuration settings + operationId: getConfig + description: + All REST catalog clients will first call this route to get some configuration provided by the server. + This route will return any server specified default configuration values for the catalog, such as + configuration values used to setup the catalog for usage with Spark (e.g. vectorization-enabled). + + Users should be able to override these values with client specified values. + + The server might be able to request that the client use its value over a value that has been + configured in the client application. How and if it will do that is an open question, and thus + not currently specified in this documents schema. + responses: + default: + description: Server-Specific Configuration Values (or Overrides) + content: + application/json: + schema: + $ref: '#/components/schemas/IcebergConfiguration' + "400": + description: Unknown Error + "401": + description: Unauthorized + /namespaces: + get: + tags: + - Catalog API + summary: List namespaces, optionally providing a parent namespace to list underneaath + description: + List all namespaces at a certain level, optionally starting from a given parent namespace. + For example, if table a.b.t exists, using 'SELECT NAMESPACE IN a' this would translate into + `GET /namespaces?parent=a` and must return Namepace.of("a","b"). + operationId: listNamespaces + parameters: + - name: parent + in: query + description: Optional parent namespace under which to list namespaces. When empty, list top-level namespaces. + required: false + schema: + type: string + example: ?parent=accounting.tax + responses: + '200': + description: OK + content: + application/json: + schema: + $ref: '#/components/schemas/ListNamespacesResponse' + '401': + description: Unauthorized + '404': + description: Not Found (Parent namespace does not exist) + post: + tags: + - Catalog API + summary: Create a namespace + description: Create a namespace, with an optional set of properties. The server might also add properties, such as last_modified_time etc. + operationId: createNamespace + requestBody: + content: + application/json: + schema: + $ref: '#/components/schemas/CreateNamespaceRequest' + required: true + responses: + '200': + description: OK + '401': + description: Unauthorized + '409': + $ref: '#/components/responses/NamespaceAlreadyExistsResponse' + + /namespaces/{namespace}: + parameters: + - name: namespace + in: path + required: true + schema: + type: string + get: + tags: + - Catalog API + summary: Load the metadata properties for a namespace + operationId: loadNamespaceMetadata + description: Return all stored metadata properties for a given namespace + responses: + '200': + description: OK + content: + application/json: + schema: + $ref: '#/components/schemas/GetNamespaceResponse' + '404': + $ref: '#/components/responses/NoSuchNamespaceResponse' + head: + tags: + - Catalog API + summary: Check if a namespace exists + operationId: namespaceExists + description: Check if a namespace exists. + responses: + '200': + description: OK - Namesapce exists + '401': + description: Unauthorized + '404': + description: Not Found + delete: + tags: + - Catalog API + summary: Drop a namespace from the catalog. Namespace must be empty. + operationId: dropNamespace + responses: + '200': + description: OK + content: + application/json: + schema: + $ref: '#/components/responses/IcebergResponseObject' + example: { "data": { "dropped": true } } Review comment: > I guess maybe my grief is with the iceberg API and the use of a boolean return value for Catalog#dropTable(TableIdentifier) to notify of an error condition whereas Catalog#createTable(TableIdentifier, Schema) would throw an exception? Using a return value could cause the error to go unnoticed if the caller is not checking the value. That's fair. So this is sort of just a sample body. We could use a 4xx here on failure, to ensure that it's not missed. And then the REST catalog could translate the correct 4xx into the drop failing. For things that are majorly issues / concerns with the Iceberg API in general, I'd suggest possibly opening a separate issue for that. The focus here is just to be able to get started on some sort of generalized enough HTTP API so that people who didn't want to write their own catalog could plug into this one (which has come up a few times from various people). For this specific one, the 200 is really what indicates the drop was successful. The body is just additional metadata really (so that it could be evolved without having to change from not parsing a body to parsing a body. That said, I agree that some sort of 4xx should be thrown if the purge was requested and didn't work. What would you suggest as far as 4xx responses go? -- 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]
