B端产品经理 对接第三方API,可能有多坑!
共 3110字,需浏览 7分钟
· 2021-08-03
本文3.1千字,来源过往项目
在IT服务外包流传一句话:做你最擅长的(核心竞争力),其余的外包!
分工协作,已经成为一种不可逆转的趋势。
同样,把“面向对象”的思想、“不重复造轮子”的古训,和生态协作的服务理念碰撞一起,似乎就很好地解释了对接API(或SDK)的重要和频繁性!
前端和后端本身无时不刻的数据互动。
公司的各个系统之间的信息共享。
与第三方业务平台的对接
比如入驻第三方销售平台亚马逊之后,要从亚马逊平台获取订单数据。
调用公共服务的公共插件,如公安系统。
上述场景,要说最难的是“与第三方业务平台的对接”。
因为人家也是做生意的,写代码的都是技术打工仔,谁也不认识谁……
这时候,坑就变得常见了!
01
曾经为一个地产老板搞过一个音视频类App项目。
引用的乔布斯的话:创新根本就不是重做新的事情,而是把既有的东西重新组合起来。
而我们做的这个App,就是“重新组合”了Soul的音视频匹配+陌陌的附近人+花椒的直播+抖音的小视频+带货,(当然后来没运营成功)。
要说的重点不是它的“创新”,而是前后一共就两个月就灰度发布了,其实是蛮快的。
因为核心的运算都是用的第三方SDK。如向芯的美颜、腾讯的鉴黄和视频拍摄、七牛的直播……
那是音视频的黄金期,服务商也有的挑,可以货比三家,每一种方案也不同收费。
开发的过程中,对这些SDK也是边做,边对比,边让产品拿主意。好在测试环境更换的成本低。
这个案例中虽然没有客服协调我们的对接进度,但是人家的接口质量OK,且选择空间大,所以最后组装起来的App测试顺利!
(参考阅读:接入SDK的需求调研案例总结)
02
曾经还主导过一个项目,是做电子合同。
对接的是法大大的SDK——这个结合了云服务+区块链等核心底层技术的SDK,提供了完善的认证外链、签章链接。
这家的客服(或商务)服务就比前面的较好!
作为对接方客户,自己做个简单的触发入口即可,其余的界面全部都可以用法大大自己的外链面完成业务。
最主要的是它的客服和实施工程师都很nice,不管是业务还是技术都对接的很到位!
所以法大大的口碑一直不错,真正“面向服务”的里面做商业服务。给对接带来了安全感!
03
过往做的最多的是商品交易类中台。所以对接更多的还是各大渠道平台,或者ERP系统。
做跨境电商的时候,印象国外的几个平台比较变态的是Lazada、JUMIA。
为啥呢?我记得它的订单维度、商品维度和一般的平台不一样,支付业务复杂导致订单与付款单等的对应关系不齐。
退货流程又复杂又维度对不上。导致你要做它的自动创建RMA单据很麻烦,容易出错。最主要是有了问题都难沟通。
后来开始对接国内的平台了,就是熟悉的美团、京东健康。这都好说,但是也会遇到坑。
比如一个平台“药某某”,居然离开API渠道就不能玩(虽然模式可选择,但是对绝大多数用户就是没得选择)。
这导致的就是,它成了一个没有楼梯的碉堡。你在里面没粮食。你要吃喝,要拉撒,都要通过一根绳子(接口)进行传输。
对方也是给个OPEN API就没有商务了(这让我想到法大大的商务和实施服务都很体贴)。也不给测试环境的用户操作页面。也不说有哪些坑。
于是我们从MVP角度出发,先对接了新增商品,结果发现一次只能增加1个商品,每分钟最多30个商品。接口要推送20来个必传字段,还是不常用的。
那就像是说,你送饭的时候,几百人在上面喊着饿,可是你一次只能递上去一碗,递不完,你还不能走。
对方说饭里要葱花,不要香草,你还要打回来重新加工后再传上去。
终于搞了数据上去,结果该平台自己的页面连删除都删不掉(之前为啥没发现功能问题,因为没数据的时候,页面功能都显示不全)。于是就要新增一个删除接口。
又发现价格也不能在平台改,又要加个修改价格的接口……
这就是阿甘说的:Life was like a box of chocolates,you never know what you’re gonna get!
04
做O2O电商中台的时候,中台是按照“销售平台+门店+商品”维度构建数据的。
一个连锁店,多的可以达到9千家门店(资本的加持下,收购比收割都快)。
而常用商品品种3000,你算算,就算只在一个平台销售,那也是2700万条基础数据(算对了吧)。
然后这些数据要通过中台,尽快地增量同步库存变化量到销售平台。
于是出现了可想而知的问题:同步池中的数据量会很大;经常量丢数据导致同步失败;用户等待时间过长。
究其原因:
触发次数多 数量大,占用线程挤满,资源不够。 销售平台限流,提交过多的数据就被限制不执行。若平台不反馈失败数据,那么失败后我们也不知道遗漏了哪些。
几次事故之后,最终除了这样的解决方案:
第一:减少来源,重点是前端的操作入口分离,并限制操作频率。 第二:对待处理数据进行清洗,去重、对比、改变存储方式等。 第三:增加失败补偿机制和日志。
具体的思路模型:
敲定场景:场景是无法无视的,场景确定,是做正确事的前提。当确定必须解决这个问题的时候,就可以静下心找方案。
控制入口:因为数据量大,所以先从来源上做增益。
清洗数据:同样是为了摆脱无效数据,尽可能降低冗余。
处理并发:通过对比、时间戳等,滤掉无效数据。
输出日志:让用户有迹可循,自行追溯。
但是实际上还是个开放性的结局,因为总会出现爆发式冲击,导致系统扛不住!
参考阅读:案例 ║ SaasS系统接口同步三方平台的优化方案
总结
好的API对开发者来说是一种向导,他也是一种优雅的服务。开发者通过URL中的每个目录节点都可以了解到该接口的大体属性。但是坏的对接,一坑更比一坑坑。
第一坑:协调沟通太难
做接口本身并不难,难的就是前期的沟通和做接口方案。
因为每个软件厂商的产品标准都不一样,要对接哪个软件系统,就必须找到对应的软件厂商,涉及的软件厂家越多,要沟通的对象就越多,如果是所谓的大数据平台的建设,需要汇集各个系统的建设,少则几家,多则几十家,往往前期协调沟通耗费大量的时间和精力。
第二坑:接口限制太高
不论是BS还是CS架构的软件系统,每个软件系统都处于厂家的势力范围。为了自身的安全,往往对非VIP客户各种浏览限制。这样就算接上了,也各种瘫痪。
数据掌握在软件厂商手里,是否开放接口、以什么方式提供接口、一个接口是几千、几万、十几万……决策权都在于软件厂商。
第三坑:接口信息不规范或自己都没做好
正如有同事说的“T迅”的代码也没好到哪里去”。有很多大厂的API你也会觉得像是实习生写的。
返回的错误信息,连转义都不给,技术工单没人理。只能忍着,被自己的用户吐槽。
第四坑:业务或数据维度不协调
别人是按规格对应销售的,你这边是按SPU销售的;别人是按自己的标库维护的资料,并且有自己的“条形码”生成规则,而你没有;别人是存在十二种优惠类型的,而你没有……直呼变态!
最后:
想学习产品层面的系统对接知识,推荐书籍<后端产品经理宝典>: