每个用户都有每日信用额度。
如果用户超出每日限制,HTTP 状态代码将显示在此处。
403 -禁止或 200 -成功(带验证结果)
最佳答案
都不是。您正在描述rate limiting 。有一个明确的状态代码:429 .
403
与安全有关,特别是授权……您是否有权执行某项操作,而不管频率如何。 403
与速率限制正交。可以这样想:如果我要求“将商品添加到购物车”,使用 403
我知道我不能,无论这是我在一段时间内的第一次请求还是我的第 N 次请求。完毕。使用 429
我知道我可以(403
没有发生或不适用),但我现在也知道我出于某种原因试图做得太快.
200
也不合适:天真的客户端只是假设一切正常,忽略任何其他细节,并默默地让用户错误地认为一切正常,而实际上发生的事情是服务器想要的说,“我现在无法处理这个问题”。
429
本身就足够了,但聪明的客户也会寻找 Rety-After header ,设计良好的 API(和 API 客户端)应该实现该 header ,以减少服务器和客户端(协作)的负载。
据推测,如果您知道如何“违反”速率限制,则可以计算出相当精确的 Retry-After
值。您可以查看 Mozilla 文档中 Retry-After 的格式。 ,可以以秒为单位或特定的日期/时间。我之前已经这样做过并添加了“fudge factor ”以避免过早出现不必要的新请求。
虽然这种方法的速率限制可能会被不良行为者滥用,但它至少有助于在服务器和客户端的标称速率限制场景中减少网络(和其他)资源利用率。
最后,429
适合您的场景,但其他状态确实需要考虑。在 之前返回
可能有所不同,具体取决于 API 和代理处理的 4xx 错误。理想情况下,最便宜的 4xx 检查首先发生(更靠近客户端)。400
、429
、403
的调用顺序(我包括 API 的整个链,包括代理) 200
关于c# - 当用户超过每日传输限制时,正确的 HTTP 状态代码是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/75879182/