缓存第 3 方 API 调用的最佳实践是什么？
我们的团队目前运营 4-5 个应用程序，所有这些应用程序都使用各种第三方服务（SimpleGeo、FB graph API、Yelp API、StrikeIron 等）。应用程序之间存在很大的重叠，并且我们经常为相同的输入参数多次调用相同的 API。显然这并不理想：速度慢且昂贵（某些 API 不是免费的）。
跨多个应用程序缓存这些 API 调用的最佳实践是什么？我看到几个选项：
- 编写一个自定义应用程序，为所有这些 API 创建外观，并更改我的所有应用程序以使用它。
- 在非常积极的缓存模式下配置某种 HTTP 代理，并通过该代理执行与 API 的连接。
我还缺少其他选择吗？
选项2有什么问题吗？您会推荐哪种 HTTP 代理（Squid、Varnish、Nginx 等）？
Our team currently operates 4-5 applications, and all of those applications use various 3rd party services (SimpleGeo, FB graph API, Yelp API, StrikeIron, etc). There is large overlap between applications, and frequently we call the same APIs for the same input parameters multiple times. Obviously that is not ideal: it is slow and it is expensive (some of the APIs are not free).
What are the best practices for caching these API calls across multiple applications? I see several options:
- Write a custom app that creates facade for all of those APIs, and change all of my apps to use it.
- Configure some sort of HTTP proxy in a very aggressive caching mode, and perform connections to APIs via that proxy.
Are there any other options I am missing?
Is there anything wrong with option 2? What HTTP proxy would you recommend for it (Squid, Varnish, Nginx, etc)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你可以使用这三种中的任何一种，但我会选择鱿鱼。 Squid 就是为此目的而创建（并且被大量使用）的（作为缓存代理）。 Varnish 被设计为反向代理（您自己的后端前面的缓存），而 nginx 更像是负载均衡器和 Web 处理器（提供文件和动态页面）。
You can use any of the three, but I would go with squid. Squid was created (and is heavily used) for this purpose (as a caching proxy). Varnish is designed as a Reverse Proxy (a cache in front of your own back-end), and nginx more like a load balancer and web processor (serving files and dynamic pages).