请求时间过长时应使用哪个HTTP响应代码? [英] Which HTTP response code to use when the request takes too long?

查看:60
本文介绍了请求时间过长时应使用哪个HTTP响应代码?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在构建一个API,该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冲突-也许吗?用户可以更改其请求以包含较小的数据集.但是我们觉得这更多是服务器问题,而不是客户端问题.

  • 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无法处理的实体-也许吗?我们将其用于其他验证错误,例如错误的日期格式或数据集名称.但这实际上不是客户端错误.

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服务不可用-但是问题通常不是暂时的.重复请求很可能会因相同的问题而失败.

503 Service Unavailable - But the problem usually isn't temporary. Repeating the request would most likely fail with the same problem.

504网关超时-从技术上讲这可能是有效的,因为我们有一个面向公众的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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆