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

[firhome]

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

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

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

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

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

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

[wunonglin]

两者都合理，具体还是看业务场景。

但第二种明显更好，毕竟你是获取 bookinfo ，其他东西没必要带给你，你再根据 bookinfo 里面的外键 id 去其他对应的接口查询即可。

这样的话再根据各个客户端的需求，去做就好了。比如页面需要一次性显示，app 不需要，那这样接口拆分的就很合理

再者就是可以“渐进式显示”，打开 bookinfo 页面，先显示 bookinfo ，然后再去请求 order ，这样用户就能先看到页面，不至于要等全部数据出来才显示。

比较复杂的例子：一个 bookinfo 里面，可能有 tags 、orders 、images 、comments ，如果全部给你，数据多的话体验会很差。那我可以先显示 bookinfo ，然后再根据用户点击的 tab ，再去加载对应的数据（懒加载）那体验会好很多，这样系统负载也会小很多，毕竟可能有的用户只是想某几个模块而已

[sunriz]

一个接口一个资源，这才是 rest api 的理念啊。适用于比较通用的业务场景，扩展能力比较好，接口干净，自描述，比如有些只需要订单，有些只需要基本信息。实际用的话如果只有你一个人用可以做一些妥协，胶水层之类的。但是如果加胶水层只服务你一个场景，放前端也问题不大，因为胶水层解决的也是一类问题，否则也是有些过度优化

[wunonglin]

@wunonglin #41

网站人流量多的可以在前端用用中间件做 ttl 缓存，网站人流量少的你也不用考虑多次请求带来的负载。

每个模块都有 curd 了，那就没必要再给你搞一个聚合接口，你说可不可以，当然可以，只是没必要而已。

[wellsc]

接口最小化原则也没啥毛病

[rabbbit]

想了一下,还是具体问题具体分析吧.

如果是像下面这样, 我觉得 2 是合理的.
1 后台订单管理界面
2 订单按书名筛选
3 从多本书里选一本 -> 展示这本书的所有订单(分页, 且此时不需要显示订单状态)
4 点击订单 -> 显示订单的详细信息

[iugo]

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

前提应该先有 book ID.

1. 根据 book ID 调用 book info.
2. 根据 book ID 调用 bookOrderList 拿到 bookOrderInfo[]

book info 和 bookOrderInfo 分开可以理解, 因为是两个业务, 但 bookOrderInfo 和 bookOrderState 分开就不理解了.

[2i2Re2PLMaDnghL]

https://max.engineer/server-informed-ui

[5boy]

@wunonglin 有道理

[hhjswf]

好奇怪的逻辑，为啥能根据 bookid 获取订单？

[Kilerd]

/books
/bboks/{book_id}/orders
/bboks/{book_id}/orders/{order_id}

这不是场景的 restful 设计场景吗？

[wuxinling]

拆分的太细了，没有必要
前年我也这么干过，先拿基本信息，再拿工作状态。
然后前端也是我自己弄（小应用），所有要用基本信息的地方，都要获取工作状态，然后就去改后端拼在一起了。
其实第二种也有好处，我自己也有单独获取工作状态的地方。
和后端说一下拼在一起就行。

[zhangmengyu]

拆分微服务没啥问题，但问题是缺少胶水层，前端--A--BCDEF 。你们的问题是缺 A ，前端直接调 BCDEF 了

[nekomiao]

单表 curd 谁不会啊，直接用代码生成器几分钟就搞完了，再花几分钟搞搞参数校验，

[nekomiao]

哪里的后端工作这么轻松啊，还缺人吗

[lucays]

3 个细粒度级别的接口肯定没问题

但是得要他再来一个聚合接口啊

[c1273082756]

骂他

[zjuster]

这就是为了强拆而强拆，完全忘记了后端的本质是为了支持业务（前端）的使用效率。
这该不是是大厂出来的人生搬硬套后端架构吧，非要把简单的事情复杂化。

后端的稳定性和存储架构要漂亮，解藕，易维护没问题，你不能让业务用的时候巨麻烦啊，怎么也要做一些业务视角服务接口吧。

@einq7 屁股板凳问题，要讲大道理都没错，后端理由比较强，因为稳定性扩展性都更强。可以指责后端不了解业务，脱离群众 ：）
打一架谁赢了听谁的

[ytmsdy]

颗粒度太小了，如果之前做微服务的话，也大概了解了。一般这么小颗粒度的 api ，都会在前面再套一层再给前端用的。
直接给前端用么也可以用，但是就是前端比较费劲了！

[C603H6r18Q1mSP9N]

5 楼 说的对

[chtcrack]

按降低服务器负载和提升客户体验来说,这样拆分越细越好,也越灵活.
就是前端比较麻烦些,但是你可以和他沟通,需要一次性拿所有数据下来的时候让他做个聚合..但是你最好别动不动就拿全部数据下来,这样服务器负载加大,客户加载也更耗费流量和资源..