什么/如何优化我的 API？

Question

这更像是一个架构问题。

我正在为一个移动应用程序设计一个 API（我们称之为 API 1），它将查询我的 API 以获取新文章。我将调用另一个向我返回原始新闻提要的 API（我们称之为 API 2）。

你问为什么根本需要 API 1？ 好吧，它会做很多优化，比如精选版特定新闻，以这样的方式格式化它让移动设备更轻松、更轻松地吸收 Feed。

所以 API 2 向我返回 1000 多个提要，然后根据我的管理假设我有 500 个提要使用 API 1 发送。现在有了缓存，这一切都对我的后端有好处。问题在于移动设备（尤其是旧设备）。他们开始大汗淋漓地响应巨大的响应（Gzip 后 270kb）。

我的解决方案：分页：

我可以将 500 篇新闻文章拆分为 5*100 篇文章。应用程序可以请求页面 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 条，

解决此类问题的最佳做法是什么？

编辑 为了更好地了解这个问题，请考虑一个类似于 Apple 新闻或 Google 报亭的应用程序，并且有点类似于 Twitter 和 facebook 订阅源。

Answer 1

您可以为每篇文章分配一个唯一的 ID，例如一个 GUID，并将这些 ID 与文章本身一起公开给 UI。然后 UI 的请求看起来像“嘿 API 1，给我文章 #id 之后的下 100 篇文章”。然后 API 1 端点将在缓存的提要中查找指定的 #id 并检索接下来的 100 篇文章。