摘要：今天，我们将跟随一位资深产品经理的视角，深入探讨在对接外部API和SDK时常见的问题和挑战，并通过4个实际案例，为你提供宝贵的避坑指南。
今天，我们将跟随一位资深产品经理的视角，深入探讨在对接外部API和SDK时常见的问题和挑战，并通过4个实际案例，为你提供宝贵的避坑指南。
在IT服务外包流传一句话：做你最擅长的(核心竞争力)，其余的外包！
分工协作，已经成为一种不可逆转的趋势。
把“面向对象”的思想、“不重复造轮子”的古训，和生态协作的服务理念碰撞一起，似乎就很好地解释了对接API（或SDK）的重要和频繁性！通常而言，系统对接的场景主要但不限于如下：
前端和后端本身无时不刻的数据互动。公司的各个系统之间的信息共享。与第三方业务平台的对接比如入驻第三方销售平台亚马逊之后，要从亚马逊平台获取订单数据。
上述场景，要说最难的是“与第三方业务平台的对接”。
因为人家也是做生意的，写代码的都是技术打工仔，谁也不认识谁……
这时候，坑就变得常见了！
曾经为一个地产老板搞过一个音视频类App项目。
引用的乔布斯的话：
创新根本就不是重做新的事情，而是把既有的东西重新组合起来。
而我们做的这个App，就是“重新组合”了Soul的音视频匹配+陌陌的附近人+花椒的直播+抖音的小视频+带货，（当然后来没运营成功）。
要说的重点不是它的“创新”，而是前后一共就两个月就灰度发布了，其实是蛮快的。
因为核心的运算都是用的第三方SDK。如向芯的美颜、腾讯的鉴黄和视频拍摄、七牛的直播……
那是音视频的黄金期，服务商也有的挑，可以货比三家，每一种方案也不同收费。
开发的过程中，对这些SDK也是边做，边对比，边让产品拿主意。好在测试环境更换的成本低。
这个案例中虽然没有客服协调我们的对接进度，但是人家的接口质量OK，且选择空间大，所以最后组装起来的App测试顺利！
曾经还主导过一个项目，是做电子合同。
对接的是法大大的SDK——这个结合了云服务+区块链等核心底层技术的SDK，提供了完善的认证外链、签章链接。
这家的客服（或商务）服务就比前面的较好！
作为对接方客户，自己做个简单的触发入口即可，其余的界面全部都可以用法大大自己的外链面完成业务。
所以是相当成熟的一次对接，也很顺利，也好理解。
最主要的是它的客服和实施工程师都很nice，不管是业务还是技术都对接的很到位！
所以法大大的口碑一直不错，真正“面向服务”的里面做商业服务。给对接带来了安全感！
过往做的最多的是商品交易类中台。所以对接更多的还是各大渠道平台，或者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！
做O2O电商中台的时候，中台是按照“销售平台+门店+商品”维度构建数据的。
一个连锁店，多的可以达到9千家门店（资本的加持下，收购比收割都快）。
而常用商品品种3000，你算算，就算只在一个平台销售，那也是2700万条基础数据（算对了吧）。
然后这些数据要通过中台，尽快地增量同步库存变化量到销售平台。
于是出现了可想而知的问题：同步池中的数据量会很大；经常量丢数据导致同步失败；用户等待时间过长。
究其原因：
触发次数多数量大，占用线程挤满，资源不够。销售平台限流，提交过多的数据就被限制不执行。若平台不反馈失败数据，那么失败后我们也不知道遗漏了哪些。几次事故之后，最终除了这样的解决方案：
第一：减少来源，重点是前端的操作入口分离，并限制操作频率。第二：对待处理数据进行清洗，去重、对比、改变存储方式等。第三：增加失败补偿机制和日志。具体的思路模型：
敲定场景：场景是无法无视的，场景确定，是做正确事的前提。当确定必须解决这个问题的时候，就可以静下心找方案。控制入口：因为数据量大，所以先从来源上做增益。清洗数据：同样是为了摆脱无效数据，尽可能降低冗余。处理并发：通过对比、时间戳等，滤掉无效数据。输出日志：让用户有迹可循，自行追溯。但是实际上还是个开放性的结局，因为总会出现爆发式冲击，导致系统扛不住！
好的API对开发者来说是一种向导，他也是一种优雅的服务。开发者通过URL中的每个目录节点都可以了解到该接口的大体属性。但是坏的对接，一坑更比一坑坑。
第一坑：协调沟通太难做接口本身并不难，难的就是前期的沟通和做接口方案。
因为每个软件厂商的产品标准都不一样，要对接哪个软件系统，就必须找到对应的软件厂商，涉及的软件厂家越多，要沟通的对象就越多，如果是所谓的大数据平台的建设，需要汇集各个系统的建设，少则几家，多则几十家，往往前期协调沟通耗费大量的时间和精力。
第二坑：接口限制太高不论是BS还是CS架构的软件系统，每个软件系统都处于厂家的势力范围。为了自身的安全，往往对非VIP客户各种浏览限制。这样就算接上了，也各种瘫痪。
数据掌握在软件厂商手里，是否开放接口、以什么方式提供接口、一个接口是几千、几万、十几万……决策权都在于软件厂商。
第三坑：接口信息不规范或自己都没做好正如有同事说的“T迅”的代码也没好到哪里去”。有很多大厂的API你也会觉得像是实习生写的。
返回的错误信息，连转义都不给，技术工单没人理。只能忍着，被自己的用户吐槽。
第四坑：业务或数据维度不协调别人是按规格对应销售的，你这边是按SPU销售的；别人是按自己的标库维护的资料，并且有自己的“条形码”生成规则，而你没有；别人是存在十二种优惠类型的，而你没有……直呼变态！
本文由人人都是产品经理作者【产品参赵】，【产品参赵】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
来源：人人都是产品经理一点号