これはアーキテクチャ上の疑問です。どのようにすればAPIを最適化できますか？
私はAPIを設計しており、APIに新しい記事を問い合わせるモバイルアプリケーション用にAPI1を呼び出しています。 Raw newsフィードを返す別のAPI（API 2と呼ぶこともできます）を呼び出します。
API 1はなぜ必要なのですか？まあ、それは、キュレーション版特有のニュースのような多くの最適化を行い、モバイルがフィードを同化するのがより簡単で軽いような方法でフォーマットします。
API 2は1000+フィードを返し、私のキュレーションに基づいて、API 1を使用して送信するフィードが500になると言うことができます。今ではキャッシュとすべてがすべてバックエンドに適しています。問題はモバイルデバイス（特に古いもの）にあります。彼らは巨大な反応（Gzip後270kb）で汗をかき始めます。
私のソリューション：ページネーション：
私は5件の* 100記事への500件のニュース記事を分割することができます。アプリは1,2,3,4および5ページをリクエストできます。潜在的短所： API 1が新鮮な記事を送信すると、5 * 100の分割が妨げられます。例えば、モバイルデバイス上のニュースフィードを参照してください。
第1条、
第2条、
..
第99条、
第100条
---ページ終了----
第101条、
第102条、
は今APIの後に1つのリフレッシュが養う：
新しい記事1、
新しい記事2、
第1条、
第2条
..
----ページ----終了
条99（重複）、
第100条（重複）
第101条、
条102、
このような問題のベストプラクティスは何ですか？問題のより良い精神的な画像を得るために
EDIT は、アップルのニュースやGoogleニューススタンドやTwitterやFacebookのフィードに多少似に類似アプリと考えてください。
ありがとうございました。しかし、それは私が望むものではありません。はい、ページがありますが、それらのページはAPI 1の応答のコンテキストにあります。アプリUIは連続スクロールフィードになります。最新の記事は、プル・ツー・リフレッシュ・イベントなどの間にのみ表示されます。 – GauravPandey
「最初のページが要求されるまで、新しく引き出された記事を表示されたリストに追加しないでください。私はこのアプローチが気に入っていますが、API 2のレスポンスはキャッシュされ、5分ごとに更新され、その揮発性のデータをメモリに保存するのは直感的になります。だから新しい記事を引っ張っても、私は最後のプルに基づいて次のいくつかの記事を取得するためのコンテキストを維持する必要があります。 – GauravPandey
申し訳ありませんが、私は助けなかった。正直なところ、問題の一貫したメンタルモデルを構築することはできないため、UI、API 1、およびAPI 2間のやり取りの詳細については、問題の説明を拡張することをおすすめします。 –