REST速率限制应该告诉调用方吗？

Question

我有一个REST，它的速率限制为每5秒每IP一个查询。当用户试图频繁调用API时，我会使用HTTP代码429 Too Many Requests和JSON消息进行响应。

现在的问题是，我是应该告诉我的API使用者允许的比率，还是应该只返回一个通用消息？

那么，根据REST原则，哪种方法是正确的呢？

{
  "error": {
    "message": "Too many requests"
  }
}

或

{
  "error": {
    "message": "Too many requests, allowed only 1 per 5 second"
  }
}

还是我应该用完全不同的方式通知来电者？

Answer 1

从API使用者的角度来看。他们向资源发送请求，并收到“现在没有”作为回复。他们怎么处理这些信息的？

• 等了50 ms再试一次？
• 等了500 ms再试一次？
• 5 S再试一次吗？
• ..。

当然，您的API文档应该说明速率限制是什么，API使用者的开发人员可以硬编码或使一个与文档对应的等待值进行配置。世界上一切都很好。

除了以后的某个时候，API的利率限制会被更改(可能是暂时的性能限制，可能是API预期的改变，或者.)。客户端突然不能正常工作，除非有人检查新的费率限制并更改代码或配置。

因此，服务器向客户端提供足够的信息是一种更好的做法，这样它就可以适应，而不必在每次发生变化时进行人为干预。希望这是构想HTTP的人所考虑的事情，他们提供了一些关于传递这种信息的预期方式的指点。所有这些都在文档里：

• 这方面最简单的文档可能是MDN上的429太多的请求页面。它说，可能会使用一个Retry-After头。
• RFC 6585是许多HTTP状态代码的权威来源。在第4节429太多的请求中，它告诉响应主体应该解释为什么请求没有被处理，并且还讨论了Retry-After头。

这两个来源可能对你来说都有点模糊。问题是，在很多情况下，它们所告诉的必须是有效的，而不仅仅是REST (或任何REST )的特定需求。因此，请考虑您的用例，考虑您的客户的需求，并在需要时尽可能具体，同时使您的实现与上述建议保持一致，并尽可能简单。