1、网络协议方面
确认接口对接的网络协议：https/http 端口号 或 tcp 端口号 Webservice
2、接口请求方面
尽量全部约定 数据传参+响应格式为：application/json
数据访问方式 POST请求
3、接口安全方面
考虑是否需要安全考虑，比如内网，外网一定要有认证机制/
4、【重要】幂等校验方面
确保 本公司接口和三方公司接口都有唯一校验功能，防止重复提交
5、【重要】重试机制方面
一定要确认是否需要接口调用失败后的重试机制，保证数据传输的最终一致性。
重试机制包括 实时重试调用指定次数 + 调用失败持久化数据库定时任务重试
6、日志记录
解密前的原始报文、解析后的报文、响应结果等，做好日志记录，方便后续排错。
幂等概念：
在计算机中编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。
使用幂等的原因：
在实际业务中，由于网络延时、失败后自动重试机制等原因，会导致一个操作重复调用多次接口，因此需要做幂等来实现相同参数调多次接口和调一次接口的结果一致，保证数据的一致性。
幂等方案实现：
唯一标识符，检查表如果已经存在该标识符的操作，如果存在，则直接返回结果；否则，执行接口业务逻辑。（如果是自定义接口，可以要求对方上送一个唯一标识，但如果是定义好的接口文档，不传这个标识的话，这个方案就无法实现）
防止抓包后恶意多次重复请求：
判断请求报文里的时间戳和当前时间戳的差值，在多久之内才算作有效请求。（如果双方服务端的时间不一致，会导致判断出错，需要保持双方系统时间的高度一致）
设想：
我们调三方获取失败结果：
a.三方失败
——如果是因为三方自身就是失败了，导致我们获取到失败的结果，那问题不大，这种情况本来就需要再次请求，不会导致重复操作。
b.三方成功返回，我们未获取到（网络超时等原因）
——会导致三方和我们数据不一致，三方认为这个操作我们完成了，我们认为没有。
——如果这种情况下我们后续的自动重试能得到正确结果，那没问题。但如果三方因为做了幂等性操作，判断我们错误重复请求而返回我们错误的结果（比如返回告知我们这是无效的重复请求），那我们无法获取到正确结果，会导致我们双方的数据不一致（比如退款审核结果通知，我们以为成功告知对方，记录订单为已退款，三方没有接受到结果，认为接口调用失败，没有做退款，那双方的订单状态就不一致了）；如果三方没有做幂等性操作，那我们可能会因为三方重复执行而获取到正确结果（比如预购订单，如果三方没有将订单号做唯一索引，可能就会重复插入，返回成功，如果做了索引，返回失败），那此时三方的数据是不对的，也可能三方因为重复执行而报错，我们依然获取到的是失败，不能得到正确结果。总之，一旦出现这种其中请求后一方成功返回数据，而另一方没有成功接收到数据，那基本 一定会导致双方的数据不一致。
三方向我们重复请求：
——可能会导致重复插入（相同参数）、接口错误（因为实际已经处理过，比如对订单的操作，取消订单）。
——幂等：时间戳 + 操作类型 + 订单号：同一个订单号一分钟内的同样操作判定为重复请求，直接返回失败。
参考：