I'd suggest using error code 422 (Unprocessable Content) [1] instead. 400 generally means the request was not well-formed (e.g. syntax error, or using invalid chars, etc.). However, here we have a situation when a client actually sends a valid request, but the server is not able to properly process some part of it.
Cheers, Dmitri. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422 On Fri, Aug 2, 2024 at 1:15 PM Amogh Jahagirdar <2am...@gmail.com> wrote: > Hey everyone, > > I'm starting this thread to discuss clarifying in the REST Spec on what > servers should do > if as part of a commit operation they receive an update > <https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml#L2570C5-L2570C16> > or requirement > <https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml#L2601> > that > is unknown. > > What I am proposing is to clearly say in the spec that if a server > receives an update or requirement which is unknown it must fail with a 400 > error code. 400 seems the most appropriate code to be able to > describe unknown input in the commit table request. Here's the PR > https://github.com/apache/iceberg/pull/10848/files > > This is a simple way to ensure that implementations avoid correctness > issues that come from ignoring unknown updates/requirements. It also > enables the community to be able to add new operations without any complex > versioning schemes. > > A more concrete example: Recently there's been work on removing inactive > partition specs <https://github.com/apache/iceberg/pull/10755>from table > metadata. With this proposal, any server which receives a > RemovePartitionSpecUpdate and does not recognize it, must fail with a 400. > > Note: I will propose the specific example of RemovePartitionSpecUpdate > spec change in a different thread. > > Thanks, > > Amogh Jahagirdar >
