请教后端同学这种写接口的方式对不对？

[firhome]

如：请求一本 book 的订单信息

[以前] 1.请求后端 bookinfo 接口，bookinfo 返回 data:{}, 包含了 book 的基本信息，book 的订单信息和订单状态(出售中，下架 等)

2.前端直接渲染数据即可。

[现在] 1.请求后端 bookinfo 接口 返回 book 基本信息 2.根据 bookinfo 接口获取 book 的 id ，再去请求 bookOrderInfo 获取订单信息 3.根据 book id 和 bookOrderInfo 里面订单 id ，再去请求个接口获取订单状态。

导致我初始化页面要发 3 个请求。

想问下 [现在] 这是个什么情况。是后端不愿意给我们包吗？喊他加数据感觉很艰难。很多东西得前端做。如果是这样的话，是不是后面前端可以写 node 来包一层？

[taine221]

我寻思说这样做没错的
没考虑过前端体验吗

[xuanbg]

这个要看具体情况的，一般来说书籍信息不包含订单信息。如果书籍信息只有一个地方使用且需要包含订单列表信息，且订单列表不需要分页的话，这两个接口合并到一起也说得过去。但直接把每个订单的详细信息一次性给你，你有地方显示？不需要点击订单列表里面的订单再跳转订单详情页面？谁会每次都去挨个查看订单详情？你前端就不嫌数据太多接口太慢？？？

所以，正常情况下，分 3 个接口一点问题都没有。

[totoro52]

面向微服务的前端，笑死 ， 主要还是看业务场景啊 这样拆也不是不行，就是多了几个请求了，如果要求一起返回的 那最好做成一个，如果是允许部分加载的那就没必要

[ZinWUT]

@firhome
感觉并不是“大佬”，要么菜要么懒，职场老油子
这种问题，直接怼回去，不能惯着。

[xuanbg]

第一个接口没什么好说的，第二个接口独立出来的目的是分页加载数据，按书籍为维度的订单，想必上万甚至几十万几百万也不稀奇。你能一次加载？？？真这样干，怕是要被用户骂死，什么垃圾玩意，打都打不开。第三个接口我就懒得说了，列表都不能一次加载，何况详情。。。。。。列表+详情，怕是 1 本书有几百个订单，系统就要崩溃了。

[fregie]

接口分的没问题啊，不通接口获取不同维度的数据，你要是有特别的需求要一个接口获取这几类不同的信息，可以加一个接口专门返回聚合过的信息

[3dwelcome]

细粒度查询没问题，比如 GraphQL 解决最大的问题，就是能忽略前端一些不需要的属性字段，减少网络流量和等待时间。

但后端这样分段查询的设计，逻辑压力就移到前端的。

我个人做法，是前端做本地缓存优化，每次 AJAX 查询前发给后端，确保一下是否需要取最新数据。

[totoro52]

@xuanbg 是的 说到底看业务场景，业务场景允许的 我是能拆多少个就多少个，但有些前端比后端还懒，喜欢在打开页面时就把所有请求打过来，比如很多个 tab 切换时，我是觉得能做懒加载就做懒加载，只有真正需要时才去请求

[mio4kon]

缺少胶水层吧

[walpurgis]

接口设计要考虑扩展性，没性能问题，原则接口越细越好，方便复用，前端还可以做局部更新
最终性能指标看 sql 执行时间就行，如果一个接口和同时调 3 个接口对数据库是一样的，我会优先分 3 个接口

[xuanbg]

@ZinWUT 我估计你怼不过。因为对方只需要把分页的需求拿出来，你就傻眼了。我就不信订单列表会没有分页。

[xytest]

体量不大，就不要把简单的事情复杂化。

[a949690645]

我认为很合理

[Macolor21]

看你们量级多大了，这后端可能是拆分了多个微服务。这种方案也好解决，你们加一个 GraphQL 就可以了，不过相当于你们后端只负责提升接口响应的性能，你们来写组装逻辑。

各有优劣吧，主要看你们业务的量级。无非就是：

1. 需要上微服务吗？
2. 拆分后，胶水层谁来做

无脑否定的人要么蠢，要么只会“啃老”。

[bk201]

要么你做一层聚合，要么后端做一层聚合。反正你们之间有个人要做。还有一点就是如果信息量能细化，虽然请求变多，但是能够在一定程度上避免整个应用因为某一个微服务问题不可用。当然，这些可以在聚合层做掉。

[micean]

所以用 graphql 搭一层中间层

[ChovyChu]

graphql +1

[chairuosen]

他拆没问题，拆完要他自己粘起来

[rabbbit]

他把数据库也拆了?

[WIN2333]

bff+1