手機：手機應用程序是一個還是兩個並行請求？

Question

我們在我們的移動Android/iPhone應用程序中使用GooglePlaces來下載附近的商店。 另外，我們在我們的數據庫中有商店，我們想要展示給用戶。

現在，只要我們的移動應用有一個位置，它會觸發兩個http請求，一個到GooglePlaces，一個到我們的服務器。只要這兩個請求都完成了，應用程序就會構建一個組合列表並將其顯示給用戶。我們在兩個請求中總共討論了50 Kb。

我們正在考慮只對我們的服務器做一個請求。然後，我們自己的服務器將向GooglePlaces發送請求，將這兩個列表合併，並將兩者都發送回移動客戶端。 優勢在於我們的移動應用只需觸發一個請求，但是當我們的服務器連接到googleplaces時，可能會增加延遲。

測試第二個選項將花費我們一整天的時間。是否有其他人遇到類似的問題？你會推薦什麼？

Answer 1

這是一個權衡，但我們有類似的問題 - 我們的應用程序提出了獨立的請求（不是googleplaces，而是其他API），我們最終轉換爲單個請求模型。我們的優勢超越了減少應用程序請求的數量。

1. 導致我們改變的最大因素是我們使用的API在相對較短的時間內部署了變更。這要求我們對代碼進行更改並重新部署應用程序。儘管如此，還是有那些沒有更新併發送支持請求的人不知道爲什麼應用程序按預期停止工作。在單一請求模型中，我們能夠避免這些更新（以及相關的支持問題）。當上遊數據提供者在API中發生變化時，我們將處理轉換爲服務器上的內部格式。
2. 與1）相關我們已經能夠在不更新應用程序的情況下合併其他數據源。當我們找到適合現有模型的新數據源時，我們可以在不更新應用程序的情況下部署它們。

3. 我們可以將部分請求緩存在服務器上。您的請求可能太局部，您需要檢查TOS是否允許緩存，但對於我們來說，我們可以通過緩存結果來緩解一些延遲。它還使我們能夠在API停機期間優雅地降級。

4. 我們能夠在將數據發送到設備之前優化數據。我們會過濾出我們所知道的服務器上未使用的任何數據元素，並優化xml，使下載大小減少20％-30％。