3

我们在我们的移动 Android / iPhone 应用程序中使用 GooglePlaces 来下载附近的商店。此外，我们的数据库中有我们想要向用户显示的存储。

现在，只要我们的移动应用程序有一个位置，它就会触发两个 http 请求，一个到 GooglePlaces，一个到我们的服务器。一旦两个请求都完成，应用程序就会构建一个组合列表并将其显示给用户。我们在两个请求中都在谈论总共 50 Kb。

我们正在考虑只向我们的服务器发出一个请求。然后，我们自己的服务器会向 GooglePlaces 发出请求，合并这两个列表，然后将两者发送回移动客户端。优点是我们的移动应用只需要触发一个请求，但是当我们的服务器连接到 googleplaces 时可能会增加延迟。

测试第二个选项对我们来说可能需要一整天的时间。有没有其他人遇到过类似的问题？你会推荐什么？

4

1 回答 1

3

这是一种权衡，但我们也遇到了类似的问题——我们的应用程序发出了独立的请求（不是向 googleplaces，而是其他 API），我们最终转换为单一请求模型。对我们来说，优势不仅仅是减少了应用请求的数量。

  1. 导致我们进行更改的最大因素是我们使用的 API 在相对较短的时间内部署了更改。这要求我们对代码进行更改并重新部署应用程序。尽管如此，仍有一些没有更新并发送支持请求的人想知道为什么该应用程序停止按预期工作。在单一请求模型中，我们能够避免这些更新（以及相关的支持问题）。当 API 中的上游数据提供者发生变化时，我们会在服务器上处理转换为我们的内部格式。
  2. 与 1) 相关，我们能够在不更新应用程序的情况下合并其他数据源。当我们找到适合我们现有模型的新数据源时，我们可以在不更新应用程序的情况下部署它们。

  3. 我们能够在服务器上缓存我们的一些请求。您的请求可能过于本地化，您需要检查 TOS 是否允许缓存，但对我们而言，我们已经能够通过缓存结果来减轻一些延迟。它还允许我们在 API 中断期间优雅地降级。

  4. 我们能够在将数据发送到设备之前对其进行优化。我们过滤掉任何我们知道服务器上的应用程序不使用的数据元素，并优化 xml，使下载大小减少 20%-30%。

于 2012-12-21T16:24:42.473 回答