kbendick commented on a change in pull request #3561: URL: https://github.com/apache/iceberg/pull/3561#discussion_r757702618
########## File path: rest_docs/rest-catalog-open-api-v0.1.yaml ########## @@ -0,0 +1,727 @@ +# +# 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: Unauthorized + + /v1/namespaces/{namespace}/tables/{table}: + parameters: + - name: namespace + in: path + description: Namespace the table is in + required: true + schema: + type: string + examples: + singlepart_namespace: Review comment: I found some of a URI standard [here](https://tools.ietf.org/html/rfc3986), though standards are often times widely not implemented in some parts so I'd rather go with what's common over anything else. From Section 2.3: > URIs that differ in the replacement of an unreserved character with > its corresponding percent-encoded US-ASCII octet are equivalent: they > identify the same resource. However, URI comparison implementations > do not always perform normalization prior to comparison (see Section > 6). For consistency, percent-encoded octets in the ranges of ALPHA > (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E), > underscore (%5F), or tilde (%7E) should not be created by URI > producers and, when found in a URI, should be decoded to their > corresponding unreserved characters by URI normalizers. > From Section 2.4: > When a URI is dereferenced, the components and subcomponents > significant to the scheme-specific dereferencing process (if any) > must be parsed and separated before the percent-encoded octets within > those components can be safely decoded, as otherwise the data may be > mistaken for component delimiters. The only exception is for > percent-encoded octets corresponding to characters in the unreserved > set, which can be decoded at any time. So it seems that the suggested approach is to slice the URL and then normalize each part if necessary. To me, that makes it seem like one `namespace` path component that it is itself URL encoded if needed (to handle dots etc) would be preferred. But that's just based on my reading of a standard. I'd also consider putting `namespace` as a query parameter, for example when listing, but would prefer not to make the endpoints too different w.r.t. parameters. I've mostly I'd love to hear any alternative views. -- 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]
