6
许多小请求与几个大请求（API设计）
我目前正在与一个组织一起从事以下项目： 客户端 -通过REST API从主服务器获取数据。 服务器 -通过第三方API向其他各种服务器请求数据 第三方API-无法控制的向服务器提供数据的服务（Reddit，Hackernews，Quora等） 出于争论的目的，假设客户端首先需要每个第三方API的项目列表。从该列表中，将选择一个项目，此时客户需要查看该项目的全部内容以及对该项目的响应（即评论）。我试图在三个选项之间做出选择： 点菜 用这种方法，我的服务器上将有3个单独的端点：一个用于获取项目列表，一个用于获取项目的主要内容，以及一个用于获取项目的响应。 优点：我从来没有发出比我需要更多的请求，请求应该很小，因此通常它们应该更快。 缺点：我必须提出很多要求。从列表中选择一个项目后，用户可能必须先等待才能看到主要内容，然后再等待更长的时间才能看到响应 服务器端缓存 在此请求中，我将对服务器进行一次调用以“获取”所有源的所有数据。然后，数据将被缓存在服务器上。然后，客户端将具有与以前相同的REST终结点，但是在两次调用之间不会有太多等待，因为我的服务器已经拥有了数据，只需要将其提供给客户端即可。 优点：仍然易于在客户端实现，但没有延迟问题 缺点：更多涉及服务器端，第一次调用可能要花很长时间。 客户端缓存 除了客户端只向服务器发出一个请求外，此方案与上一个相似：将所有数据提供给我。从这里开始，客户有责任保存数据并正确使用它们。 优点：易于服务器实施，在首次通话后非常快速 缺点：第一次调用将非常缓慢，客户端实现更为复杂 我不确定哪种方法是最好的，或者不确定是否缺少明显的解决方案。任何建议将不胜感激！