问题
I'm building an API that does analytics on a very large database we are storing. Some requests take a very long time to process. We want to proactively abort requests that take more than 10 minutes, but we don't know if a request will take that long until we try it. Most of the time, it's not because of transient server overloading. It's that the user made a request involving so much data that we simply can't get through it fast enough.
I've scoured the list of standard HTTP response codes but I can't find one that clearly fits:
409 Conflict- Maybe? The user could change their request to involve a smaller data set. But we feel like it's more of a server issue, not a client one.422 Unprocessable Entity- Maybe? We use this for other validation errors like bad date formats or dataset names. But it's not really a client error in this case.Other
400-level codes - It's not a bad request or an auth issue. We think we should service the request but we can't.500 Internal Server Error- Maybe this? But it feels too generic. This is what comes with bugs and unexpected issues.501 Not Implemented- Maybe? We kind of haven't implemented support for requests that involve an excessive amount of data. But the RFC seems to imply this is for when the request method isn't implemented. But the method is not the issue here.503 Service Unavailable- But the problem usually isn't temporary. Repeating the request would most likely fail with the same problem.504 Gateway Timeout- Technically this could be valid because we have a public-facing API service which proxies these requests to an internal service. But we don't necessarily want to expose this implementation detail to customers.
Which is most appropriate / least bad? Or is there another I should consider?
回答1:
If you want to indicate that it is server side error and user can retry request - use 5xx
But it looks like in you case you want to say to user your query is too big, change it before retrying, so you should use 4xx
So, I'd go with 400 Bad Request.
来源：https://stackoverflow.com/questions/48940802/which-http-response-code-to-use-when-the-request-takes-too-long