kbendick commented on a change in pull request #3561: URL: https://github.com/apache/iceberg/pull/3561#discussion_r760547087
########## 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: + value: "accounting" + multipart_namespace: + value: "accounting.tax" + - name: table + in: path + description: Name of the table to load + required: true + schema: + type: string + example: "sales" + get: + tags: + - Catalog API + summary: Load a given table from a given namespace + operationId: loadTable + responses: + '200': + description: OK + content: + application/json: + schema: + $ref: '#/components/schemas/GetTableResponse' + '401': + description: Unauthorized + # Using 412, `Precondition Failed`, instead of 404, as 404 makes monitoring response codes from ELBs + # very difficult - Hard to tell if clients or servers are misconfigured and calling non-existent routes + # or missing routes versus expected error cases such as NoSuchTableException (expected meaning that + # a person who is on call shouldn't be paged for this but 404 they might need to be). + '412': Review comment: I've worked at some companies where our operations team has asked us to change off of explicitly returned 404. I agree that services should have metrics etc, but many load balancers themselves cant be configured with this additional information. It often has to go within user's applications. That said, I've definitely been in outage situations where more custom metrics / app metrics are down, and one of the few signals left is raw ELB response codes (which can usually be retrieved outside of normal in-app metrics systems people use). There's also precedence for departing from standard REST conventions for internal monitring. For example, for all "valid" requests, Facebook strictly returns a 2xx for monitoring purposes. I'm open to using 404, but I don't personally subscribe to the belief that we should ignore making internal monitoring easier for the sake of purity to the REST standard. Additionally, if we had 412 and 409, we'd be able to easily see what caused the "404" type response. Plain 404 everywhere wouldn't indicate what was missing without further metrics. I'm not closed off to using 404, but that's my reasoning. I think it's healthier to try to work with whatever internal teams might be responsible for monitoring and to allow as many avenues as possible to determine what went wrong, especially if we presume that inevitably certain metrics might temporarily not be available when we need them most. So there's precedence both ways. I'm going to leave it for now but am happy to continue the discussion 🙂 -- 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]
