这更像是一个架构问题。
我正在为移动应用设计一个API（我们称之为API 1），该应用将查询我的API以查找新文章。我将调用另一个API（我们称之为API 2），它将Raw新闻源返回给我。
你问为什么需要API 1？ 那么，它会像策展版特定的新闻一样做很多优化，以这样的方式格式化它移动设备更容易轻松地吸收饲料。
所以API 2会向我返回1000多个提要，然后根据我的策展，我可以说我有500个使用API发送的提要。现在有了缓存，所有这些对我的后端都有好处。问题在于移动设备（尤其是旧设备）。他们开始以巨大的反应出汗（Gzip之后270kb）。
我的解决方案：分页：
我可以将500篇新闻文章拆分为5 * 100篇文章。该应用可以请求第1,2,3,4和5页。 潜在利弊： 当API 1发送新文章时，5 * 100的分割会受到干扰。例如，请参阅移动设备上的新闻Feed：
第1条，
第2条，
...
第99条，
第100条
----页面结束----
第101条，
第102条，
现在，在API 1刷新Feed之后：
新文章1，
新文章2，
第1条，
第2条，
...
----页面结束----
第99条（重复），
第100条（重复）
第101条，
第102条，
针对此类问题的最佳做法是什么？
修改 为了更好地了解问题，想想一个类似于Apple新闻或Google newstand的应用程序，有点类似于Twitter和Facebook提要。
答案 0 :(得分：1)
您可以为每篇文章指定唯一的ID，例如GUID，并将这些ID与文章本身一起公开。然后UI的请求看起来像“嘿API 1，在文章#id之后给我下100篇文章”。然后API 1端点将在缓存的Feed中查找指定的#id并检索接下来的100篇文章。