当请求时间过长时使用哪个 HTTP 响应代码? [英] Which HTTP response code to use when the request takes too long?
问题描述
我正在构建一个 API，用于对我们存储的非常大的数据库进行分析.有些请求需要很长时间来处理.我们想主动中止需要超过 10 分钟的请求，但在我们尝试之前，我们不知道请求是否需要那么长时间.大多数情况下，这不是因为暂时的服务器过载.原因是用户提出的请求涉及大量数据，我们根本无法足够快地通过它.
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.
我已经搜索了标准 HTTP 响应代码列表，但我不能找到一个完全合适的:
I've scoured the list of standard HTTP response codes but I can't find one that clearly fits:
409 Conflict- 也许?用户可以更改他们的请求以涉及更小的数据集.但我们觉得这更像是服务器问题，而不是客户端问题.
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 - 也许?我们将此用于其他验证错误，例如错误的日期格式或数据集名称.但在这种情况下，这并不是真正的客户端错误.
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.
其他 400 级代码 - 这不是一个错误的请求或身份验证问题.我们认为我们应该为请求提供服务，但我们不能.
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 - 也许是这个?但是感觉太一般了.这就是错误和意外问题带来的后果.
500 Internal Server Error - Maybe this? But it feels too generic. This is what comes with bugs and unexpected issues.
501 未实现 - 也许?我们还没有实现对涉及过多数据的请求的支持.但是 RFC 似乎暗示这是在未实现请求方法时使用的.但方法不是这里的问题.
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 - 但问题通常不是暂时的.重复请求很可能会因同样的问题而失败.
503 Service Unavailable - But the problem usually isn't temporary. Repeating the request would most likely fail with the same problem.
504 Gateway Timeout - 从技术上讲，这可能是有效的，因为我们有一个面向公众的 API 服务，它将这些请求代理到内部服务.但我们不一定要向客户公开此实施细节.
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?
推荐答案
如果你想表明是服务器端错误并且用户可以重试请求 - 使用 5xx
If you want to indicate that it is server side error and user can retry request - use 5xx
但看起来你想对用户说你的查询太大，在重试之前改变它，所以你应该使用4xx
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
所以，我会选择 400 Bad Request.
这篇关于当请求时间过长时使用哪个 HTTP 响应代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
