1

正在考虑的 API 有两个限制：

  • 每日限额。
  • 并发限制。

如果请求没有排队，应该提供什么 HTTP 响应代码？

到目前为止，这两个选项似乎是 409 和 503。也就是说，503 似乎表明 API 服务器本身存在问题，而不是调用它的用户已经用尽了他们的配额。

4

3 回答 3

5

进一步阅读后，发现429 Too Many Requests（RFC 6585）。

429 请求过多


429 状态码表示用户在给定时间内发送了太多请求（“速率限制”）。

响应表示应该包含解释条件的详细信息，并且可以包含一个 Retry-After 标头，指示
在发出新请求之前要等待多长时间。

例如：

HTTP/1.1 429 Too Many Requests    Content-Type: text/html   
Retry-After: 3600

    <html>
       <head>
          <title>Too Many Requests</title>
       </head>
       <body>
          <h1>Too Many Requests</h1>
          <p>I only allow 50 requests per hour to this Web site per
             logged in user.  Try again soon.</p>
       </body>    </html>

请注意，本规范没有定义源服务器如何识别用户，也没有定义它如何计算请求。例如，
限制请求速率的源服务器可以基于
每个资源、整个服务器甚至一组服务器之间的请求计数来执行此操作。同样，它可能通过其身份验证凭据或有状态的 cookie 来识别用户。

带有 429 状态代码的响应不能由缓存存储。

这似乎正是我想要的。

谢谢你的其他答案。

于 2013-05-17T01:17:52.480 回答
2

我认为没有适当的地位。Twitter弥补了这一420 enhance your calm地位。只要您记录它，就没有问题。

在我看来403 Forbidden，即使您指定了原因，RFC 也会说SHOULD不会重复请求。这让我想到只要我不修改该请求就会被拒绝。

于 2013-05-17T00:58:03.103 回答
1

一些 API 供应商使用 503 表示您超出了根据 API 使用条款指定的速率限制。

Amazon EC2 和各种 Google API 也在做同样的事情。尝试在“503 速率限制”上进行 Google 搜索，您会发现很多 API 都与此相关。只要您提供详细的消息并且您的 API 文档清楚地提到它，您的 API 的用户应该可以接受。

于 2013-05-17T05:32:55.253 回答