Which catalog configuration should we return if we specified the prefix and warehouse at the same time?
Yufei Gu <[email protected]> 于2026年4月2日周四 06:08写道： > > Yes, let's! > Yufei > > > On Wed, Apr 1, 2026 at 3:00 PM Kevin Liu <[email protected]> wrote: >> >> I've seen a couple of +1s on the spec PR: >> https://github.com/apache/iceberg/pull/15746 >> >> Shall we move this to a vote? >> >> On Sat, Mar 28, 2026 at 2:21 PM Kevin Liu <[email protected]> wrote: >>> >>> We can use `IcebergErrorResponse` to differentiate between route doesnt >>> exists (404) and resource/warehouse doesnt exists (404). This is what the >>> spec PR describes, >>> https://github.com/apache/iceberg/pull/15746/files#diff-02549ca620d020dc9ead80088cc14e311e12a69651fa8d394cd41a4308debb2eR165-R173 >>> >>> For example, >>> `google.com/v1/config` doesnt exist, so >>> ``` >>> python3 -c "import urllib.request; >>> urllib.request.urlopen('http://google.com/v1/config')" >>> ``` >>> returns `urllib.error.HTTPError: HTTP Error 404: Not Found` >>> >>> And I would expect an IRC endpoint to return `NoSuchWarehouseError` >>> instead, with `"type": "NoSuchWarehouseException"`. >>> >>> Best, >>> Kevin Liu >>> >>> On Sat, Mar 28, 2026 at 10:08 AM Steven Wu <[email protected]> wrote: >>>> >>>> Chatted with Yufei offline. The `warehouse/catalog` is a hidden concept in >>>> the REST spec. If we could redo it, including it in the path (instead of >>>> as a query parameter) might make more sense. E.g., The endpoint could look >>>> like "/v1/{prefix}/config," where a 404 status would be perfect. >>>> >>>> Since it is too late to change that, I agree 404 is fine here. >>>> >>>> On Fri, Mar 27, 2026 at 10:00 AM Ryan Blue <[email protected]> wrote: >>>>> >>>>> I think the difference between those examples and the config route is >>>>> that those examples identify resources that do not exist (namespace in >>>>> both cases). We also have cases where you could get a 404 indicating a >>>>> namespace or a table does not exist, but that indicates that the resource >>>>> you're looking for either does not exist (table) or can't exist >>>>> (namespace preventing table from being present). >>>>> >>>>> The config endpoint always exists, which is why this is odd. I think you >>>>> could argue that this is okay because it isn't really a resource that has >>>>> create/update/delete operations. I just don't know what the "correct" way >>>>> to handle this is in REST APIs. But then I've never been one that's too >>>>> strict about REST principles. >>>>> >>>>> On Thu, Mar 26, 2026 at 3:44 PM Yufei Gu <[email protected]> wrote: >>>>>> >>>>>> I'd be cautious about 204 since it indicates a successful response. 404 >>>>>> seems fine to me. IRC spec uses it in multiple places, like [1] and [2] >>>>>> to indicate that certain entities do not exist. >>>>>> >>>>>> 1. >>>>>> https://github.com/apache/iceberg/blob/9534c9b3adc29d127ecc541ce131f49fd72f1980/open-api/rest-catalog-open-api.yaml#L539 >>>>>> 2. >>>>>> https://github.com/apache/iceberg/blob/9534c9b3adc29d127ecc541ce131f49fd72f1980/open-api/rest-catalog-open-api.yaml#L490 >>>>>> >>>>>> Yufei >>>>>> >>>>>> >>>>>> On Thu, Mar 26, 2026 at 2:03 PM Steven Wu <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> 404 may not be the best fit, as it generally indicates that the >>>>>>> endpoint itself could not be found. The endpoint receiving the query >>>>>>> parameters exists, and a lack of results is a valid outcome of the >>>>>>> search/filter operation, not a client error in forming the request URI. >>>>>>> >>>>>>> Maybe return 204 No Content as the request itself was valid and >>>>>>> successfully processed. >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 26, 2026 at 1:48 PM Ryan Blue <[email protected]> wrote: >>>>>>>> >>>>>>>> This seems reasonable to me. I don't know if 404 is the right response >>>>>>>> since the endpoint always exists, but it's fine with me. >>>>>>>> >>>>>>>> On Wed, Mar 25, 2026 at 6:04 PM Yufei Gu <[email protected]> wrote: >>>>>>>>> >>>>>>>>> It seems reasonable to add the 404 response. I noticed that the >>>>>>>>> warehouse parameter is optional. I assume this is meant for catalog >>>>>>>>> implementations that support exactly one catalog or warehouse here so >>>>>>>>> that client is OK to skip it, though please correct me if I am >>>>>>>>> mistaken. In that case, a 404 would still make sense when that single >>>>>>>>> warehouse is not yet ready. >>>>>>>>> >>>>>>>>> parameters: >>>>>>>>> - name: warehouse >>>>>>>>> in: query >>>>>>>>> required: false >>>>>>>>> >>>>>>>>> >>>>>>>>> Yufei >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Mar 24, 2026 at 8:33 AM Kevin Liu <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Thanks for raising this proposal! I think it makes sense to add this >>>>>>>>>> to the spec and be explicit about the error case. I found the place >>>>>>>>>> where Apache Polaris throws `NotFoundException` for the `/v1/config` >>>>>>>>>> endpoint. The specific error `type` field can be used to >>>>>>>>>> disambiguate a route 404 (URL doesn't exist) from a resource 404 >>>>>>>>>> (URL is valid, but the server cannot find the warehouse). >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Kevin Liu >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://github.com/apache/polaris/blob/67daa9bb479eaa0ee6c4428984e253afc01b6efd/runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalogHandler.java#L1360 >>>>>>>>>> >>>>>>>>>> On Tue, Mar 24, 2026 at 4:34 AM Oğuzhan Ünlü >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi everyone, >>>>>>>>>>> >>>>>>>>>>> I'd like to propose a small addition to the REST catalog spec: >>>>>>>>>>> documenting HTTP 404 as a valid response for the /v1/config >>>>>>>>>>> endpoint when a requested warehouse does not exist. >>>>>>>>>>> >>>>>>>>>>> The Rationale >>>>>>>>>>> >>>>>>>>>>> The /v1/config endpoint allows an optional query parameter for a >>>>>>>>>>> warehouse identifier, e.g. /v1/config?warehouse=mywarehouse. But >>>>>>>>>>> the openapi spec does not specify what should happen if the >>>>>>>>>>> requested warehouse does not exist. >>>>>>>>>>> >>>>>>>>>>> Snowflake Open Catalog already returns a 404 for non-existent >>>>>>>>>>> warehouses: >>>>>>>>>>> >>>>>>>>>>> ``` >>>>>>>>>>> { >>>>>>>>>>> "error": { >>>>>>>>>>> "message": "Unable to find warehouse >>>>>>>>>>> NONEXISTENT_WAREHOUSE_12345", >>>>>>>>>>> "type": "NotFoundException", >>>>>>>>>>> "code": 404 >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> ``` >>>>>>>>>>> >>>>>>>>>>> This proposal therefore formalizes what Snowflake Open Catalog is >>>>>>>>>>> already doing in production. It seems sensible to formalize the 404 >>>>>>>>>>> response code, because this is consistent with other Iceberg REST >>>>>>>>>>> endpoints which allow a 404 response code for missing resources >>>>>>>>>>> (tables, namespaces, views). >>>>>>>>>>> >>>>>>>>>>> The Proposed Solution (PR-15746) >>>>>>>>>>> >>>>>>>>>>> Add a NoSuchWarehouseResponse to the OpenAPI spec for the >>>>>>>>>>> /v1/config endpoint, formalizing 404 as the response when a >>>>>>>>>>> warehouse does not exist. You can view the PR here: >>>>>>>>>>> https://github.com/apache/iceberg/pull/15746 . >>>>>>>>>>> >>>>>>>>>>> Looking forward to your thoughts. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Oguzhan
