许多异步调用与对API的单次调用

我们正在开发REST API，其中的HTML5前端将通过javascript使用REST API。该应用程序供组织内部使用，通常有大约300个用户，但我们希望扩展到1000个左右的用户。

通常不会在LAN内建立与API的连接，因此连接的质量和延迟会很好，尽管不排除偶尔会在Internet上使用3G / 4G时连接速度较慢且滞后时间较长的情况。

我们认为的两个选择是：

1. 前端将同时对API进行多次异步调用，以加载接口的各个组件。

   • 优点：简单。
   • 缺点：与服务器的连接更多。

2. 前端的控制器将对API进行一次调用，将需要获取的对象作为参数传递给参数。

   • 优点：尽管服务器将与数据库建立多个连接，但仅与服务器建立一个连接。
   • 缺点：在前端和API中都需要机制。它使设计复杂化。

进一步说明：将有不同的资源... /产品... /位置等。可以单独获取这些资源，但是将有另一个抽象资源... / screen？Product＆Locations将在一次调用中获取。

选项1（多个异步调用）是最佳选择，因为：

1. 每个单独的调用都是其自己的实体，因此如果发生某些故障，您可以单独重试。在整体式“一次呼叫”架构中，如果一件事失败，则必须再次执行整个呼叫
2. 服务器端代码将更加简单：模块化，这意味着不同的开发人员可以使用不同的API资源
3. 在典型的MVC模式中，让一个API调用加载多个独立的资源是没有意义的 ; 例如，如果您请求/products获取要显示在页面上的产品列表，并且还希望显示销售流行产品的地点列表，则您有两个单独的资源：Product和Location。尽管它们显示在同一页面上，但是您不能在逻辑上拨打电话/products并使其返回位置
4. 使用模块化方法，您的日志记录/利用率报告将更加简单。如果您向发出请求，/products并且还正在加载位置，那么您的日志文件将会非常混乱
5. 如果你有一个特定的资源问题，一个呼叫的方式会导致整个页面打破，它不会很明显你的用户是什么打破了 -这意味着它会需要更长的时间为您的团队来解决问题; 但是，在模块化方法中，如果一件事情坏了，很明显什么坏了，您可以更快地修复它。它也不会破坏页面的其余部分（除非事情太紧密地耦合在一起……）
6. 如果事物分开，则一般更容易进行更改；如果您通过一个API调用加载了5种资源，那么当您要更改某些内容时，将很难弄清楚如何不破坏某些内容

整个问题是资源是分开的，即使在“保存到服务器的连接”中，在REST API中从单个API路径返回许多单独的资源也没有意义。顺便说一句，使用参数有条件地加载（不同）资源不是RESTful的。

综上所述，唯一的逻辑选择是发出多个异步请求以分离资源：采用模块化方法！

PS-不要过早地优化“与服务器的连接”，特别是当HTTP连接的开销非常低且您位于LAN上时。这种想法不是立即选择更简单的设计，而是会让您日后陷入困境。