这更像是一个架构问题。
我正在为移动应用设计一个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篇文章。