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