我的目标是将 Web 应用程序与内部数据库同步。Web 应用程序有一个公共 API，但为了完全同步这两个源，我每次都需要进行大约 2000 次单独的 API 调用。我的直觉告诉我，这是过度的，可能是不负责任的，但我缺乏确定的经验。
在这种特殊情况下，Web 应用程序是Asana，但我之前在使用其他服务时遇到过类似的情况。有什么方法可以知道您是否通过过多的 API 调用来滥用服务？我知道我不会去 DOS 像 Asana 这样的公司，但我无法摆脱这样的感觉：肯定有比每天发出约 15 万个请求更好的方法。
我能想到的唯一其他选择是仅当我知道数据库发生更改时才更新 Web 服务，但那样我会失去很多功能。
我为这个问题的主观性道歉，但我真的希望有人能解释在使用公共 API 时是否有任何礼仪。
（我在 Asana 工作）
这是一个很好的问题，或者说是一组问题。
您正在设计一个系统，该系统将重复对每个对象发出请求。随着对象数量的增加会发生什么？即使您的初始请求率是合理的，这也会遇到可伸缩性问题。一种更具可扩展性的解决方案是随着系统中更改的数量而扩展的解决方案。这也会随着时间的推移而增长，但速度要慢得多 - 单个用户每天可以进行的更改数量相对恒定，但他们创建的对象总数会随着时间的推移而增长和增长。所以我的第一条建议是避免以这种方式做事，而是找到一种方法来检测变化并采取行动。知道为什么你觉得通过这种方法会失去能力会很有趣。
现在，我碰巧知道 Asana API 目前没有为您提供任何友好的机制来检测系统中的变化。这是一个普遍要求的功能，我们正在研究它，但遗憾的是我不能保证交货日期。因此，您可能别无选择，只能暂时轮询我们的系统。
至于对 API 的礼貌，许多服务提供商对其 API 的使用设置了限制，以防止意外或恶意使用 API 影响对其其他客户的服务——Asana 也不例外。有时会发布这些限制，有时不会发布，并且没有标准限制：这完全取决于服务。但是您对服务限制感到好奇是非常周到的。
也就是说，对于 Asana API 来说，每天 150k 的请求已经很多了。如果我们所有的 API 用户都为我们提供了这么多流量，那么我们每天服务的请求可能比 Google Web Search 还多，而且我们还没有那么大的可扩展性。:) 从技术上讲，有时，我们可能会处理来自单个用户的那个量的请求。
如果您必须轮询，请尝试每隔 15 分钟轮询一次。但请不要在这段时间内轮询您的整个工作区；这可能是太多的流量/数据。我们正在努力为您提供更好的解决方案。
如果您碰巧对 Asana API 发出了太多请求，您将返回 HTTP 状态代码 429 而不是您想要的响应；您可以在此处阅读更多相关信息（https://asana.com/developers/documentation/getting-started/errors）。