• 前端该如何反驳后端API通用性的问题?
  • 发布于 1周前
  • 161 热度
    6 评论
原因:App 开发的时候,首页有 4 个相同的模块,在了解到数据是同一个服务提供的,所以希望后端在提供接口的时候能够一次将这个这四个模块的数据整体返回给我。

结论:服务端的大佬说为了保证接口的原子性,不要做太多业务上的事,他们会开发一个通用的接口,有几个模块让我调用几次。其次服务端考虑到后面可能其他的服务也会调用,所以希望能尽可能通用。

以上结论在前后端对接时他们时常用这个说法对我进行 pua ,我觉得我已经无法接受了,请问各位大佬,这种情况如何反驳?为了保证他们接口的原子性,我大部分页面通常都要 2-5 个接口,甚至更多,比如之前获取图片,因为他们的图片是两张表,一张是图片 id ,一张是 id 对应的图片地址。我只能先获取 id ,再用 id 去请求接口。但服务的通用性在这个说法我在长期对接中发现纯属扯淡,几乎只有我在对接且因为接口调用的多了增加各种复杂场景,如果没有处理好也会影响用户体验。
用户评论
  • 李明发
  • 一个数据列表返回了 10 条数据,每条数据上都有 5 个图片 id ,前端先调取数据接口,渲染的时候再分别调取 5 次图片接口,除非图片接口可以直接返回图片,否则我是接受不了。
  • 2024/4/29 12:28:00 [ 0 ] [ 0 ] 回复
  • 张蜚
  • 人家没毛病,接口设计尽量简洁,不要大而全,至于你想一下子把数据请求全了,可以自己二次加工,在自己的 repo 层合并。
  • 2024/4/29 12:26:00 [ 0 ] [ 0 ] 回复
  • 莫逆于心
  • 「比如之前获取图片,因为他们的图片是两张表,一张是图片 id ,一张是 id 对应的图片地址。我只能先获取 id ,再用 id 去请求接口」。这种完全就是 sql 的逻辑,客户端为什么要关心对接方的内部设计,把接口细节暴露出来增加对接方理解成本真的很好?

    你对接的后端做着业务后端的工作,但用着基础服务的心态提供接口。同意前面大佬所说的,提供一层聚合层/业务后端层来解决这个问题。我觉得客户端使用的接口就要提供视图所要求的数据,试想一下如果产品以 api 接口提供对外服务,提供这样的 api 能力,感觉客户得把你骂死。自己人折磨自己人也是很正常,这些 dirtyworks 谁都不想做,但总是要做,就看公司内部话语权了。
  • 2024/4/29 12:18:00 [ 0 ] [ 0 ] 回复
  • 相视一笑
  • 我觉得这就是两码事,后端接口原子性是一码事,数据聚合又是另一码事。其实本质问题就是看新加的业务数据聚合层到底是谁做,如果后端负责就让他去做,如果要放到前端,那就你去做呗。写个 Promise.all 的事
  • 2024/4/29 12:10:00 [ 0 ] [ 0 ] 回复
  • 脸庞灿烂
  • 我是写后端的;
    「服务端考虑到后面可能其他的服务也会调用,所以希望能尽可能通用」这句话看起来也没有问题,保证接口的单一职责的确很重要,但归根到底,这是接口开发者的职责,不是接口使用者的义务;
    如果「单个接口返回需要的多个数据」需求是成立,那么接口怎么实现以及将来怎么复用是后端需要考虑的问题,后端只要提供这个接口就好,不能教对接方做事吧;
    但是「单个接口返回需要的多个数据」是否真的成立,比如不在一个接口返回,非常难渲染界面;
    如果仅仅是因为「数据是同一个服务提供的」就希望「一次将这个这四个模块的数据整体返回」在我看来这是不够具有说服性的——这相当于将前端组合接口的工作转移到了后端(属于“损人利己”),所以后端需要拒绝,然后就找了一些通用啊、复用啊这类的“说辞”(虽然也有道理)
    至于 pua ,九字真言呗;
    吐槽归吐槽,还是要解决问题:给后端一个不能拒绝的理由很重要;如果只是针对某一个人,为了维护自己的利益,那么引入第三方——各自的 leader 或者资深程序猿,也是一个方法;
  • 2024/4/29 11:50:00 [ 0 ] [ 0 ] 回复
  • 搁浅双手
  • 设计上应该保持各个方法/接口的原子性,但是给到前端的接口可以根据业务具体情况让后端自己整合一下。当然也可以不整合。但是图片分两张表/两个接口有点奇怪,两张表不是可以联表查出来一起给到前端嘛,反正都是 url ,又不会有多大。我只能说你举的例子不够明确具体,最好给个例子。
  • 2024/4/29 11:47:00 [ 0 ] [ 0 ] 回复