我们在我们的移动 Android/iPhone 应用程序中使用 GooglePlaces 下载附近的商店。 此外,我们的数据库中有商店,我们希望向用户展示。
现在,只要我们的移动应用程序有一个位置,它就会触发两个 http 请求,一个到 GooglePlaces,一个到我们的服务器。一旦两个请求都完成,应用程序就会构建一个组合列表并将其显示给用户。我们谈论的是两个请求中总共 50 Kb。
我们正在考虑只向我们的服务器发出一个请求。然后,我们自己的服务器会向 GooglePlaces 发出请求,合并两个列表,然后将两者发送回移动客户端。 优点是我们的移动应用程序只需要触发一个请求,但当我们的服务器连接到 googleplaces 时可能会增加延迟。
测试第二个选项可能需要我们一整天的时间。还有其他人遇到过类似的问题吗?你会推荐什么?
最佳答案
这是一种权衡,但我们遇到了类似的问题——我们的应用发出独立请求(不是针对 googleplaces,而是针对其他 API),我们最终转换为单一请求模型。对我们来说,优势不仅仅在于减少应用程序请求的数量。
- 导致我们更改的最大因素是我们使用的 API 在相对较短的时间内部署了更改。这要求我们更改代码并重新部署应用程序。尽管如此,仍有一些人没有更新并发送了支持请求,想知道为什么该应用程序停止按预期运行。在单一请求模型中,我们能够避免这些更新(以及相关的支持问题)。当 API 中的上游数据提供者发生变化时,我们会在服务器上处理到我们内部格式的转换。
- 与 1) 有关,我们已经能够在不更新应用程序的情况下合并其他数据源。当我们找到适合我们现有模型的新数据源时,我们可以在不更新应用程序的情况下部署它们。
我们能够在服务器上缓存我们的一些请求。您的请求可能过于本地化,您需要检查 TOS 是否允许缓存,但对我们来说,我们已经能够通过缓存结果来减轻一些延迟。它还允许我们在 API 中断期间从容降级。
我们能够在将数据发送到设备之前对其进行优化。我们过滤掉我们知道服务器上的应用程序未使用的任何数据元素并优化 xml,因此下载大小减少了 20%-30%。
关于android - 移动:移动应用程序发出一个对两个并行请求?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13990839/