和三方的关系要处好；

01

如果你看到这个话题，并不知道是什么意思，那么祝贺你，安安静静的当个小码农也挺好；

不过我敢说，随着职业生涯的慢慢发展，大家都得碰到，到时候就细细体会吧；

那年，我双手插兜，不知道什么叫三方对接；直到入职了一家金融公司后，承接了一个需求：跟银行对接数据流水；

从此就一发不可收拾，踏上了漫漫对接路，之后跟三方对接的活，都被我全部承包了；直到我后来办理离职手续，写的交接文档上，除了跟xxx对接，就是yyy对接；

后来想想，也没有那么不堪，我大致梳理了的下，分为以下几个点：

如果想做好对接，每个环节上都不允许出现问题；否则，由于某个环节拉胯，就会导致整盘对接停滞，最终，项目延期交付；

说到延期交付，那你就做好被开大会的准备吧；

会议上那是“八仙过海，各显神通”；大家各说各的，反正，并不是自己的问题；谁想背锅？背锅就是绩效问题，就是money问题；

02

【对接文档】
哦，在说对接文档之前，我还不得不提一下对接之前的事宜；

公司商务人员或业务人员可能会频繁的出差，有时候还会把你们技术老大叫上，为啥？还不是为了避免聊到技术问题，不会解答，让他兜底去的；

好吧，继续说回对接的事情；

一般拿到这种跟甲方对接的需求，对方会有文档抛过来的；至于这个文档是什么形式，反正五花八门，可真实有用的内容，也就那么几行；

在对接的文档中，我们主要关心的还是以下几个要点：加密方式、接口、传输形式；

首先，加密方式；每个对接的三方各有各的要求，一般都会对请求报文做加密、加签等处理，或者请求做授权处理；也不排除少部分不需要做处理；

请求报文加密：可以使用对称性加密，非对称性加密等方式；对称性加密，就是使用同一个密钥，对数据进行加解密，这样相对来说安全性差点；所以会使用非对称性加密的方式较多，非对称性加密，三方会生成一个密钥对，分为私钥和公钥，私钥三方保存，用来对数据解密；公钥提供给我们，我们通过公钥对数据进行加密；

请求报文加签：与上面一样，使用非对称性加密方式，对于原始数据进行加签；只不过这里需要注意的是，密钥对是自己生成的，自己保存私钥，用私钥对数据签名，把原始报文和签名后的报文，一起传给三方；然后三方通过我们提供的公钥进行验签；

如果用两种方式一起使用，是可行的；如果在实际情况下，那就根据甲方的要求，具体使用哪种方式吧；万一，他们要求不需要什么加密，这，也没毛病；

总结一下就是；

加密：保证数据不被泄露，公钥加密，私钥解密；

验签：保证数据不被篡改，私钥加签，公钥验签；

私钥：自己保存；

公钥：公开，可多人持有；

请求授权处理：有些三方接口，在你请求之前，需要对方开通apiKey和appSecret，然后拿到一个授权的token；在请求业务接口的时候，需要将这个token一并带过去，否则，请求无效；

这个不难理解，为的就是给系统接口多一层保障；看对方怎么要求，就怎么做吧；

最后还会有一层保障，在网络层面，双方运维会配置IP白名单；

第二个，传输形式；首先得看清接口的协议，常见是HTTP、HTTPS，少部分也是会用SOCKET，RPC等方式；

报文的格式：我觉得常见的还是两种，一种是JSON形式，另一种是XML形式；JSON格式主要搭配的是HTTP或HTTPS协议，常见的系统都是这么对接；XML格式一般会和SOCKET搭配，少部分会用这种形式，比如银行系统；

最后，接口本身；这个也是最重要的环节，言外之意就是接口的字段；包括字段的命名、类型、限制长度、业务意义等；

字段命名，这个没什么好讲；几乎所有系统都是英文命名，在英文命名的基础上，许多系统会采用驼峰命名法；

字段类型，一共几种形式；

字符串，这种类型想必大家都不陌生，是最常见和最常用的一种类型；

数值，主要是金额、年龄、数量等，会上该类型，包含浮点和整型；

对象，它是基础类型的综合，如字符串、数值、对象等，统一组合在一起，组成一种业务意义的类型；比方一个学生对象类型，包含姓名（字符串）、年龄（数值）、班级（对象）；

集合，就是一种或多种同类型的对象；还是学生的例子，把一个或多个学生对象放在一起，就组合成一个集合类型；

如果还需要三方将数据传输给我方系统的话，那就需要我们提供接口和接口文档了；

写接口，那是开发方面的事情，暂且不谈；提供接口文档，其实也是个技术活；

由于是我方的接口，一般上文讲的方面，都是我方决定的，但是，总有个别特例；

我曾经遇到过，明明是对方需要调用我方接口，可是，接口文档，传参，传输方式，协议等等，都已经“帮”我们定好了；

惊呆了，老铁！好吧，谁让你是甲方呢；

言归正传，正常流程是我们定义好自己的接口，然后再根据接口，拟定一份文档，文档内容无外乎就是上文提到过的内容；

编写接口文档的工具有很多，大家可以参考我之前写的《文档&工具》篇，里面具体列举了好用的一些工具；

总之，拿到对接文档，并且提取上面有用的内容，只是整个对接流程的第一步；

最后再说一遍，接口的字段很重要，千万别弄错了！

03

【对接沟通】
熟读对方提供的接口文档之后，其实还不能进入开发阶段；原因无他，就是这份文档并不是最终的版本，它需要在沟通的过程中不断去修改和完善；

需要沟通什么？总不会和别人去聊家常吧，当然是在看文档的过程中发现了你把握不住的问题，或者有疑问的业务场景；

和谁沟通？这时候你需要沟通的有两类人，一个是我方的业务经理或产品经理，另一个是三方的开发；

对应的问题找对应的人，当你觉得业务上有疑问，可以跟自家产品经理去进行battle；当你们产品经理不懂技术的时候，那么事情就变得简单多了；

在不影响最终功能的前提下，可以尽可能将技术实现变得简单点，这是跟自家产品讨论需求的核心要素；反正他不清楚技术实现，就使劲忽悠，总之自己要讲的有理有据，真假结合；场面堪比旺仔碰到奥姑，一个真敢说，一个真敢信；

但是有那么一小部分产品经理，他是懂点技术的，或者他就是开发转的产品，那就当我没说；

回归文档本身，当你觉得接口存在问题，那就不得不找到三方的开发了；

最后一顿沟通下来，如果对方文档是有问题的，就绕不开文档的修改和调整，务必让对方将调整过的文档发过来，记得做好文档变更，最好将上一版的文档也一并保留；

沟通途径：一般常见的有群聊、电话、会议、内部通讯软件等等；最后还有一种，叫口头沟通，这种方式水很深，坑很大，要小心提防，至于为何，懂的都懂；

在对接过程中，沟通是必不可缺的一个环节，良好的沟通能够提高效率和产出，与其说是和第三方对接，倒不如说和三方保持沟通；

04

【协调资源】
协调其实也是沟通的另一种表达方式，只不过协调过程中会涉及更广的方面，所以单独拿出来说说；

所谓协调，其实是对资源的协调，资源大致分为三种：人力、时间、成本；

人力资源：即参与对接流程的所有人；

我方人员主要涉及后端开发，运维，测试；这里的这几类人，包括我方和三方的人，这里没有将前端开发归类进去，因为一般不会涉及到前端开发；

整个对接流程环环相扣，一旦某个环节卡壳，就会导致下一步不能进行下去；

在不同的环节下，都会有不同的人去参与，如果你是主导开发，就需要合理发挥自己的协调能力，将每个环节的人合理利用起来，记住要保持高效的沟通；

时间资源：就