kbendick commented on a change in pull request #3561: URL: https://github.com/apache/iceberg/pull/3561#discussion_r766217147
########## File path: rest_docs/rest-catalog-open-api-v0.1.yaml ########## @@ -0,0 +1,657 @@ +# +# 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 possible catalog-specific + configuration values provided by the server, that the catalog (and its HTTP client) + can use to complete the `initialize` step. + + This call is similar to the initial set-up calls that some catalogs already do for + domain-specific information, such as the Nessie catalog or the Glue catalog. + This is to allow for services that would like to integrate with Iceberg to do so, + and to be able to add their own domain-specific information into the REST catalog without + requiring them to write and distribute a catalog themselves. + + There will be two sets of values provided - + + - overrides + * An object containing values that the client must use. + For example, auth headers that the client will receive from the server + as temporary credentials. + - defaults + * Catalog-specific configuration that the client may use as a default value. + These are optional and the client is free to use its own value for these. + + responses: + default: + description: Server-Specific Configuration Values (or Overrides) + content: + application/json: + schema: + $ref: '#/components/schemas/IcebergConfiguration' + example: { + "data": { + "overrides": { + "prefix": "/raul", + "headers": { + "User-Agent": "Raul", + "Authorization": "Basic Ym9zY236Ym9zY28=", Review comment: I don't see it as being too different from a `/login` endpoint tbh. Here's what I found for some basic login information on the web: https://mobile-security.gitbook.io/mobile-security-testing-guide/general-mobile-app-testing-guide/0x04e-testing-authentication-and-session-management#testing-stateful-session-management-mstg-auth-2 - The app sends a request with the user's credentials to the backend server. - The server verifies the credentials If the credentials are valid, the server creates a new session along with a random session ID. - The server sends to the client a response that includes the session ID. So this particular example of sending back the exact `Authorization` header might not be how it's done, but outside of the route being called `config`, it's not unheard of for a client to exchange its credentials for temporary session credentials (or otherwise), which it then uses for the lifetime of the app. The above is more or less how I've done authentication on other applications. It could in theory be moved to a dedicated route, but the idea is to allow for people to implement authentication according to their own measures. The specification for this one catalog isn't intended to be incredibly strict in how things are defined, so that it can fit several people's usages (e.g. people who use different forms of authentication for things). -- 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]
