对接后端接口被挑战能力不行(吐槽贴,不会因为这个问题去挑战什么)

查看 466|回复 48
作者:svip0dd   
原因:App 开发的时候,首页有 4 个相同的模块,在了解到数据是同一个服务提供的,所以希望后端在提供接口的时候能够一次将这个这四个模块的数据整体返回给我。
结论:服务端的大佬说为了保证接口的原子性,不要做太多业务上的事,他们会开发一个通用的接口,有几个模块让我调用几次。其次服务端考虑到后面可能其他的服务也会调用,所以希望能尽可能通用。
以上结论在前后端对接时他们时常用这个说法对我进行 pua ,我觉得我已经无法接受了,请问各位大佬,这种情况如何反驳?为了保证他们接口的原子性,我大部分页面通常都要 2-5 个接口,甚至更多,比如之前获取图片,因为他们的图片是两张表,一张是图片 id ,一张是 id 对应的图片地址。我只能先获取 id ,再用 id 去请求接口。但服务的通用性在这个说法我在长期对接中发现纯属扯淡,几乎只有我在对接且因为接口调用的多了增加各种复杂场景,如果没有处理好也会影响用户体验。
bigfei   
自己建立个 BFF 层,扩大代码的 ownership ,防御性编程。
Gil86002618   
写个 BFF 层处理吧,其实服务端说的也没错,有些服务就是基础服务,跟具体的业务无关,需要考虑接口的通用性。
hging   
你想想如果明天产品跟你说 要再加一个数据 那你是让后端给你加接口方便还是用通用的自己接方便。
lambdaq   
接口原子性最后的进化就是客户端直连 sql 。
woodfizky   
设计上应该保持各个方法/接口的原子性,但是给到前端的接口可以根据业务具体情况让后端自己整合一下。
当然也可以不整合。
但是图片分两张表/两个接口有点奇怪,两张表不是可以联表查出来一起给到前端嘛,反正都是 url ,又不会有多大。
我只能说你举的例子不够明确具体,最好给个例子。
unco020511   
可以自己加个中间层处理下,对于你的业务还是调一个接口
vacuitym   
其实分开比较好,你想一下四个模块有一个出问题了,你希望是只有三个模块数据正常展示还是说四个数据全部无法展示
FEontheway   
让后端再另外提供一个聚合接口调这个通用服务不就行了。而且多个接口同时调用,各个模块展示顺序也不好控制,不会影响用户体验吗
lzgshsj   
为什么要反驳?用着不爽就自己弄 BFF 。另外这种事情不应该让你们的 leader 定调吗
您需要登录后才可以回帖 登录 | 立即注册

返回顶部