合并多个HTTP请求以节省带宽是否是一个好主意？

我正在准备一个单页应用程序，该应用程序有时会在缓慢的移动连接上使用。就API请求而言，它的某些部分相当繁重（为新的屏幕显示获取10个不同的资源）。

现在，将这些服务合并到提供所有必需数据的服务中，但是就REST原理而言不是“纯”的，这是一个好主意吗？是否会有可观的性能提升？

REST的优点之一是能够通过传统的http缓存来缓存请求（假设这些请求是可缓存的请求）。

当您有单个，较大，使用频率较低且可能不同的请求时（a,b,c,d这次我要获取项目，a,b,d,e下次要获取项目），则使该请求更有可能是缓存未命中，并从可能是坐在您和来源之间的某个地方。

给定上面提到的两组请求，第二个请求的缓存命中率可能为75％，并且基本上只获取e而不是全部四个东西的速度要快得多。

请注意，这对于使用它的人可能不是立即显而易见的，因为执行第一组高速缓存未命中请求的人仍将具有高速缓存未命中。

这并不是说在移动网络连接上比较理想，因为这种连接不太可能获得非本地缓存命中。但是对于热点或其他wifi情况，缓存命中可能会更有用。

同样，其中的大部分取决于应用程序的工作方式。它在启动时是否要求所有这些数据？还是我们在谈论响应时间预期不同的页面加载？

理想的操作是对其进行测试，以查看您的应用程序在各种情况下的性能。考虑设置一种情况，将您的移动设备绑定到可以监控的本地wifi网络（这只是Google的第一击），并模拟不良的互联网连接以查看实际情况（或不正常）以及哪一个表现最好。

您的直觉在某种程度上是正确的-从总体上讲，减少请求数量当然是可取的；矮胖的API往往更好。尤其是在连接混乱的情况下，您可以看到一些工作，有些却无法创建噩梦般的后备情况，因为没有任何东西可以依靠任何东西。

有一个很大的警告-您可能会变得过于笨拙，并且您的呼叫和响应变得肿。例如，当您第一次点击页面时，有一个大电话可能是有意义的，然后以较小的比特数发送更新，而不是每次需要数据时都强制刷新大页面。

或者，您将极有可能想同时使用两种方法。

查看这篇Dropbox Tech Blog文章。

在那里，他们详细描述了为什么以及如何完全实现您提出的用于为所有图片检索缩略图的解决方案。应该说，他们确实评估了性能，以查看是否值得解决该麻烦，而且显然是值得的。

简短的摘要：

Dropbox网站必须加载数百个缩略图。由于某些浏览器的限制，并非所有缩略图都并行加载（请求已排队）。他们想使用SPDY，但由于系统的某些部分尚不支持SPDY而无法使用。最后，他们使用了基于HTTP的批处理请求，这些请求以压缩形式返回每个响应多个缩略图。根据他们的结果，总体页面加载时间缩短了40％。

简而言之：您的方法在某种程度上是正确的，并且可以从包装服务中受益。

该服务将现有的单个调用合并为一个服务端方法。通过合并从客户端到服务端的调用并利用您现在可能已经存在的所有单个的，原子的，宁静的调用来做到这一点。

因此，您将继续受益于REST作为缓存请求的能力。

但是，到最后，一切都会归结为应该消耗它的服务/服务器基础结构性能和客户端环境。