- 1,在设计接口前一定要把相关逻辑梳理清楚,不论是对方,还是自己
逻辑都不清楚写出来的接口文档一定有问题,逻辑复杂的话建议画下时序图或流程图征得双方的认可
- 2,形成良好的接口文档规范
一般的接口文档都要有
文档作者
创建日期
更新日期
当前版本
修订历史
接口逻辑描述
接口网络协议
请求格式
测试地址
生产地址
请求参数详细设计
返回参数详细设计
请求示例
返回示例
加解密规则 等等
双方如有歧义一切以接口文档为准
- 3,测试环境和正式环境尽可能一致,协议等接口规则要一模一样
如果测试的是http协议的接口,生产变成https协议,对方告诉你不需要证书就能调通,也不用绕过证书。
你试了一下确实能通,但也不要感觉麻烦,不好意思拒绝,博主以惨痛的经历告诉你一定要坚持拒绝。
测试的时候一直是协议的接口,上线当日对方告诉我http变成https了,不用证书就行,我试了一下确实如此。
过了一个月我们去验收,突然发现接口不通了,问对方开发,他又说需要绕证书,不是说不用吗,问他们改啥东西了没,
死活不承认,没变任何东西怎么可能一会通一会不通的。
我紧急的又改了代码,四个接口通了三个,剩下的预约单接口不通问对方原因,对方说是我的类别有问题,要用他们提供的,我说以前不是这样的啊,就这样断断续续的扯皮扯了两周,周六日都不得安宁。隔了两天又突然说不是类别造成的,用postman请求就没问题,我心中一万个马奔腾而起。我又看看了一下他返回的错误信息:请求格式错误!。我想让他发一下具体的错误信息,说来说去就是不发,后来更是不理了,真没见过这样的人,因为你变协议,导致接口不通,你还不配合排查原因。
和领导反应领导还只说是我的问题,人家用postman请求就没问题,也不帮我在群里说句话,真是哑巴吃黄连有苦说不出。没办法我只能比较别的接口请求成功的接口参数,发现这个接口有数字类型的和布尔类型,还有中文,我一个个把可能的错误原因排查掉发现是中文编码的问题,问题终于解决了。
想想当初如果不接受协议变更就没那么多破事了。
- 4,对接时尽可能与对方开发处好关系
双方开发如果沟通顺畅的话,接口的事也就那样没啥难度。就怕不配合变来变去的那种伪开发。或者根本就没开发,一个实施丢你一个接口文档,让你去对接,搞来搞去根本不知道哪错了,最后用抓包工具才发现报文不一样,改了报文才正确
- 5,在页面上可查询接口相关日志
把入参,状态变化,接口名称等关键信息在接口处存库,如果接口有问题可在页面上可快速查询到日志消息,减少双方扯皮的时间,不用再登录上远程服务器上看日志,有的时候你还远程不了服务器,这页面上的日志就很关键了,