许多小请求与几个大请求（API设计）

我目前正在与一个组织一起从事以下项目：

• 客户端 -通过REST API从主服务器获取数据。
• 服务器 -通过第三方API向其他各种服务器请求数据
• 第三方API-无法控制的向服务器提供数据的服务（Reddit，Hackernews，Quora等）

出于争论的目的，假设客户端首先需要每个第三方API的项目列表。从该列表中，将选择一个项目，此时客户需要查看该项目的全部内容以及对该项目的响应（即评论）。我试图在三个选项之间做出选择：

点菜

用这种方法，我的服务器上将有3个单独的端点：一个用于获取项目列表，一个用于获取项目的主要内容，以及一个用于获取项目的响应。

• 优点：我从来没有发出比我需要更多的请求，请求应该很小，因此通常它们应该更快。
• 缺点：我必须提出很多要求。从列表中选择一个项目后，用户可能必须先等待才能看到主要内容，然后再等待更长的时间才能看到响应

服务器端缓存

在此请求中，我将对服务器进行一次调用以“获取”所有源的所有数据。然后，数据将被缓存在服务器上。然后，客户端将具有与以前相同的REST终结点，但是在两次调用之间不会有太多等待，因为我的服务器已经拥有了数据，只需要将其提供给客户端即可。

• 优点：仍然易于在客户端实现，但没有延迟问题
• 缺点：更多涉及服务器端，第一次调用可能要花很长时间。

客户端缓存

除了客户端只向服务器发出一个请求外，此方案与上一个相似：将所有数据提供给我。从这里开始，客户有责任保存数据并正确使用它们。

• 优点：易于服务器实施，在首次通话后非常快速
• 缺点：第一次调用将非常缓慢，客户端实现更为复杂

我不确定哪种方法是最好的，或者不确定是否缺少明显的解决方案。任何建议将不胜感激！

要记住的一件事是客户端和服务器之间的预期网络延迟（即ping时间）。在高带宽的情况下，高延迟情况下，许多小请求的执行将明显比大请求差。

我最近一直在一个由多团队支持的网络应用程序项目中进行协作，其中一个团队在印度（其余团队在美国）。我们在美国办公室托管一个数据库实例，开发人员将我们的本地Web服务器实例连接到该数据库实例。我的办公桌可能距数据库实例50英尺，距局域网实例只有两个LAN，并且性能很好。

当我们刚开始接触印度的开发人员时，他们经历了漫长的等待时间，需要启动应用程序以及逐页导航。我们在这里说的是十分钟的等待时间。事实证明，这是因为从他们的办公桌到我们的开发数据库服务器的〜200ms ping时间正乘以许多很多对数据库的简短查询。我本地的0.5毫秒ping非常琐碎，以至于Web服务器和数据库服务器之间的聊天状态不再重要。这是我们第一次在Web服务器和数据库服务器之间进行地理隔离。

在我们的案例中，解决方案是克隆数据库服务器并在印度站起来，但要注意的是，如果客户端和服务器相距较远，则网络延迟将乘以跨服务器的通信数量。线。建立连接后的带宽通常不用担心。

这三个选项不是互斥的，您可以结合使用客户端缓存和服务器缓存。但是，如果某些数据（例如注释）在高速缓存中保存的时间过长，则可能会过时。考虑到您无法检查是否是这种情况，您应该完全避免存储它。另一方面，内容通常不会发生很大变化，因此在服务器端缓存它，然后在客户端预取其中的一些内容以降低延迟不会有任何危害。

仅基于您提供的信息，选项1，因为

• 如果有一个客户请求，您将混合苹果和橙子，并且水果篮可能很大。

• 缓存是一种折衷，您可以在其中获得性能，但有可能失去一致性（陈旧数据）。如果您没有发现任何性能问题，则通常不值得冒险。

我总是发现一些较大的请求具有更好的性能和更大的可伸缩性。但是在所有方法中都需要权衡取舍，因此这取决于服务器和客户端的需求。您可能希望使用另一个选项，即让客户端指定要检索的整个范围或一组数据-不一定是所有数据，而是某些范围，可以随时间调整以匹配可用带宽。

我会（几乎）打折选择3。在1和2之间进行选择取决于两件事：

• （A）一次总取回的结果有多大
• （B）客户/用户通常在该会话中使用多少结果细节。

容易决定A和B是否为极端：

• 如果A大而B小，则肯定要选择选项1（点菜）。
• 如果A小而B大，则选择2（服务器端缓存）或什至3（客户端缓存）。

对于其他任何A / B（大/小）变体，您都必须谨慎行事。我通常会提供两个粗，细端点，以满足不同用户不同的使用情况。

和编程一样，这取决于。

因此，真正的问题是：在决定A / B / C或三者结合时应考虑什么？

我要说的是，真正的区别因素是您使用的第三方API的实现细节。例如，您应该考虑：它们是快还是慢？数据是否经常且意外地更改？他们是“闲聊”还是休息？

如果是快速，易于调用的服务，并且数据变化如此频繁，以至于服务器端缓存将造成陈旧的缓存问题，那么，请务必选择方法1：更多请求，仅在需要时才没有缓存。

如果您的外部数据将以可预测的方式发生更改，或者您的使用受到限制，或者仅是您可以获得更好的用户体验在服务器上缓存数据，请选择2。但是请记住，缓存不是免费的：它的调试成本很高，有时用户会抱怨看不到更新。

选项3，我只会考虑数据不多的情况，但是在那种情况下，即使选项1或2都可以工作，并且您在服务器上保留了更多的逻辑，所以我坚持使用1或2。

只是我的2c。