The distinction between 200 and 204 is subtle enough that I'm comfortable using them interchangeably in this context. My main concern is that, if we make this change, all clients—except for PyIceberg—will need to be updated to support both 200 and 204, since a server could return either status code. It might not be worth it.
Yufei On Tue, Dec 17, 2024 at 12:52 PM Kevin Liu <kevinjq...@apache.org> wrote: > Hey folks, > > I’d like to propose adding status code 200 as a valid response for HEAD > requests in the Catalog REST API. Currently, the following HEAD requests > return status code 204 for a successful response: > * namespaceExists > <https://github.com/apache/iceberg/blob/540d6a6251e31b232fe6ed2413680621454d107a/open-api/rest-catalog-open-api.yaml#L372-L402> > * tableExists > <https://github.com/apache/iceberg/blob/540d6a6251e31b232fe6ed2413680621454d107a/open-api/rest-catalog-open-api.yaml#L1129-L1160> > * viewExists > <https://github.com/apache/iceberg/blob/540d6a6251e31b232fe6ed2413680621454d107a/open-api/rest-catalog-open-api.yaml#L1691-L1712> > > In PyIceberg, support for status code 200 has already been implemented for > table_exists > <https://github.com/apache/iceberg-python/pull/1389/files#diff-3bda7391ebd8aa3dcfd6703d8d2764830b9d9c35fa854188a37d69611274bd3dR890> > and namespace_exists > <https://github.com/apache/iceberg-python/pull/1434/files#diff-3bda7391ebd8aa3dcfd6703d8d2764830b9d9c35fa854188a37d69611274bd3dR882>. > The motivation for this change is to enable more intuitive and > user-friendly integrations with catalogs, as Fokko highlighted here > <https://github.com/apache/iceberg-python/issues/1363#issuecomment-2497462825>. > Standardizing this behavior in the Catalog REST spec would promote > consistency across implementations and make interactions easier for users > and client developers. > > Would love to hear your thoughts on this proposal! > > Best, > Kevin Liu >
