[GitHub] [iceberg] jackye1995 commented on pull request #3561: [CORE] Specification for an HTTP REST catalog

[GitBox <gi...@apache.org>]

jackye1995 commented on pull request #3561:
URL: https://github.com/apache/iceberg/pull/3561#issuecomment-984945739


   > 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.


-- 
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: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org