javascript - 网站前后端分离问题,API编写

网站前后端分离问题：
例如 首页是由多个模块组成，每个模块有自己的API接口，
前端人员让我把数据一次返回给他，我需要再对接口进行组合，
请问这样好不好？还是他通过多次请求分别获取数据好

回复内容：

网站前后端分离问题：
例如 首页是由多个模块组成，每个模块有自己的API接口，
前端人员让我把数据一次返回给他，我需要再对接口进行组合，
请问这样好不好？还是他通过多次请求分别获取数据好

说个重一点的方案，但可能没有回答你的问题。

按照大前端的概念，如果中间加一个Node层，对前端可以完成服务端渲染，对后端可以整合API。而且这个由前端来维护，不求后端，自己折腾。 ：）

资源消耗相同或资源消耗比较小的情况下 一个接口能够搞定的事不要写两个接口

Node，go等高并发的做api。最好不要一次发，从restful api来说这么玩不好。等于后端随着前端的变化在不断变化，不适合解耦和模块化。前端可以做好缓存，减少交互，比如redux，数据的缓存。不要每次都到后端拿数据，就是一次给数据也挡不住啥都到后端拿，也是大量交互。很多都拿到之后可先用缓存，有个时间间隔或者用户点了刷新之类的再去服务端拿数据。

一次好吧，毕竟 HTTP 请求还是越少越好吧，，你就多写几行代码的事吧

不同角色，看问题的角度是不同的。
站在前端角度，可能就是一个请求都返回了，减少了 http 的请求，性能提高了，前端能就少发几个请求。
站在后端角度，就是分模块写接口，清晰明了。

我本身是后端，我的一般观点就是 【觉得合适，开发难度不大，不影响你】，就合并一起吧，在返回的数据里，根据不同 key 也可以做到模块的区分，后期增加、删除模块，也很容易。

大家的角色不同，没必要非要争对错，这种没有绝对，没有绝对适合任何情况的解决方案，灵活处理。

当然，你也可以坚持。

如果返回的数据很多，比如几十页的分页数据，这个肯定需要依据分页来获得数据。

如果返回的数据不多，不会因返回的数据多而对性能造成影响（即可以忽略不计的影响），那么建议一次返回，因为这样可能大大减少了前端的工作量，同时因为请求数据的次数不是很频繁，对性能也是有好处的。

你们不会用HTTP 2.0吗？

HTTP 2.0 多次请求，一次发送，你值得拥有。

还有，如果后台是RESTful的，组合接口破坏了逻辑，十分伤。如果前端不知道RESTful的话，把他开了吧。

额，新开一个接口，将不同模块数据按要求组合下就好了。反正不同模块都封装好了，调用下就好了，这个接口也专门用来做这个用途，不要混用。