kbendick commented on pull request #3561: URL: https://github.com/apache/iceberg/pull/3561#issuecomment-986426702
> > 412 feels weird. the fact that some people may have load balancers in front and some load balancers standard config aren't clear about what 404 means isn't a great reason for a non-standard overload of a return code. > > I agree with Ryan. I think the general principle of an OpenAPI specification is to express the theoretical behavior of the APIs, without consideration of infrastructure setup. There can be so many layers of infrastructure and redirection in between your service and the client, you can never predict what error could happen in between. > > ELB has a well-defined list of error codes, and counters for all of them, users can filter out what errors are from ELB and what are not if they really want to. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html > > REST APIs are resources based, here the resources are `namespsace` and `table`. 404 of `/namespaces/ns` clearly indicates namespace `ns` does not exist, I don't think there is ambiguity related to that. > > 412 has a very specific meaning that "the server does not meet one of the preconditions that the requester put on the request header fields", we should not overload the meaning. > > I would suggest looking at some well-known APIs to see how they are defining error codes, such as https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html. Although S3 is not REST but RPC, but the error code aspect is the same. That's a good point regarding infra complexities in between. I always said I'd be fine with reverting to 404s, and I'm very much convinced now. I think there might be some use cases for additional code usage (e.g. a renameTable request where the namespace to rename the table to does not exist), but I'll revert everything to 404 for the foreseeable future. 👍 -- 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]
