我从（Java Spring）服务器向我的（JS）客户端提供RESTful API。 主站点页面包含许多逻辑块（新闻，最后评论，一些趋势内容），每个逻辑块都在服务器上有相应的实体。哪种方式是正确的，处理一个请求，如
/api/main_page/ ->
{
news: {...}
comments: {...}
...
}
或让客户做一些请求，比如
/api/news/
/api/comments/
...
我知道一般来说，有一个大的请求/响应会更好，但这也是对这种情况的回答吗？
答案 0 :(得分：1)
理想情况下，您应该使用不同的API调用来从同一API中获取页面的各个可配置内容块。
这样你的内容块就会相互松散。
您
可以扩展，移植（到新框架）并在其中独立修改它们
随时随地。
这在应用程序增长时非常有用。
关闭功能非常简单 情况下。
在这种情况下，A / B测试也很容易。
编写自动化是 也很容易。
总体而言，它有助于减少测试工作。
但是如果你真的想在一次通话中取这个。然后你应该在请求中添加额外的参数，当服务器看到另外的参数时，它会通过从BL层调用它自己的方法在响应中添加额外的独立JSON。
并且，如果速度是您的关注点，那么尝试在服务器上缓存这些调用一段时间（取决于应用程序的类型）。
答案 1 :(得分：0)
我认为，当请求的资源反映系统状态的某些部分时，通常可以证明多个请求是合理的。 （我个人的经验法则，仍然是WIP）。
即。如果news在您的客户端应用程序中显示很多，我会请求它一次并在任何可能的地方重复使用它。如果你在这里聚合，你需要稍后请求，也许其中一些永远不会实际显示，如果news的表示在聚合和/news/{id}中有所不同，你就会有一些魔力-resource。
如果页面第一次加载，这种方法会增加通信，但是在运行的时间越长，整个客户端应用程序的通信就会减少。
服务器上的状态通过请求复制请求到您的客户端或在需要时更新（Etags，最后修改等）。
在您的示例中，/news和/comments似乎是某种最新或自上次访问，但不是所有。
如果这是真的，我会将它们设计成一个重新出现，如/comments/latest或类似的。
但无论如何，我只会分别与/news/{id}或/comments/{id}进行自我链接。然后，您会向/comments/latest请求news - 自我链接列表中的内容，以便在我尚未拥有news时才会启动请求（也许我想检查缓存的副本是否仍然是最新的。）
只有在/news/{id}实际显示（滚动，滑动）时，才可以触发news请求。
comment或book的生命周期可能是回答此问题的标准。这意味着客户端中的缓存对于系统来说并不重要，与书店应用程序中的fgets相反。