在对接第三方的过程中，有时候明明是一个简单的业务，对接却那么复杂。到底是什么原因造成了这样的局面呢？本文将对此进行探讨，一起来看看吧。
前段时间在产品经理的交流群里遇到一位小伙伴发表的疑惑：
刚好笔者之前也对接过另外一家第三方电子合同平台，本文就以电子合同为例，探讨一下：为什么第三方平台对接越来越复杂？
笔者注：为了便于阐述观点和确保内容的易读性，文中涉及的流程均做了一定程度的简化，不能作为对接第三方电子合同平台的对接参考，请读者注意分辨。
我之前在《新手产品经理必学技术接口文档知识》中讲过，在设计开发产品的时候，产品需要用到某些功能，但这些功能的实现对于现有的团队而言，可能缺乏业务领域的优势，或缺乏技术领域的优势，亦或两种领域的优势都明显不足，因此往往需要通过对接第三方平台来实现，像上文那位小伙伴提到的“电子合同”，因为涉及严格的备案和鉴权，在国内，能够做这个业务的公司屈指可数，因此多数公司的产品只能选择对接有资质的第三方平台。
但在对接第三方平台的过程中，暴露出的问题越来越明显，就是明明只需要实现一个非常简单的业务，但是接口方提供的接口非常多，让产品经理觉得对接起来非常复杂，那么，到底是什么原因造成了这样的局面呢？
要想解答这个问题，首先要从对接方的角度，看看最简单的对接流程应该是怎么样的，再来分析为什么接口提供方没有办法按照最简单的流程来做。
从对接方的角度，以上流程虽然对接了4个接口，但实名认证和签署只需通过链接跳转到对接平台的页面进行操作，因此其核心对接步骤只需两步：
那么为什么对接平台不能提供这样一个简单的流程给到对接方，而是每个环节都要弄出一大堆接口出来，主要是基于以下考虑。
以生成待签署文件为例，有两种场景，一种是业务平台直接生成待签署文件上传到第三方平台；另一种则是业务平台上传模板到对接平台，然后往模板中填充内容并生成待签署文件，两者的大致作业流程如下：
通过以上作业流程可以发现，无论是直接上传待签署文件，还是通过模板生成待签署文件，最开始的时候都需要做一个上传的动作，两者只是上传的文件不同而已，因此，在设计接口的时候，获取文件上传地址和上传文件这一步往往可以设计为2个接口，而非4个接口，系统只需根据上传的场景在接口参数中标记清楚当前文件是属于待签署文件还是模板即可，比如用“file”表示待签署文件，用“template”表示模板。
因此，把接口拆得更细，能够兼容更多的场景，同时能够提高部分接口的复用率，如果根据业务流程把一堆接口封装成一个接口，那么上文提到的两个场景中，将有部分接口内容属于是“重复造轮子”。
在电子合同签署流程中，有一个环节叫做“签署流程归档”，归档的概念是表示文件已经签署完成，不能再对该文件发起签署，我们想象的归档流程和真正的归档流程分别是这样的：
是不是感觉莫名其妙又多此一举，明明一个接口能够搞定的事情，偏偏还要多调用一个归档接口之后，电子合同平台才进行归档，但如果我告诉你以下两种场景，你应该就能够理解这个设计的意图了：
因此，在平台设计接口的时候，就已经考虑到各种不同的场景，所以将一些重要环节的决策权交还给业务平台去决定，从而使得流程更加灵活。
在签署合同过程中，我们想象中签署流程和真正的签署流程分别是这样的：
我们想象中的签署流程是一蹴而就的，然而真实的场景中，从平台发起签署流程到签署人进行签署，或多人签署的场景等到最后一人完成签署，都是需要等待一段时间的，这段时间可能很短，也可能很长，但系统不可能一直在那里等着（loading），因此，就有了一个“异步通知”的概念，异步通知可以理解为某个流程的完成需要一定的时间，在这段时间内，业务系统无需做任何处理，等到该流程完成后，对接平台会通过另外一个接口来通知业务系统，业务系统再进行后续处理，这个接口，就是异步通知接口。
以上文的签署流程为例，假设一个多人签署的流程，在全部签署人签署完成后进行归档，其流程是这样的：
除了上文提到的原因，拆分接口对于平台的商业性而言，也有一定的优势，比如上文提到的签署流程中，签署人需要先通过平台进行实名认证，拆分实名认证接口，等同于将实名认证的业务与电子合同签署的业务进行分割，如果有客户只需要实名认证的服务而不需要电子合同签署业务，则可以将该业务独立开来进行收费。
所以，现在你知道，为什么第三方平台对接越来越复杂了吧？
以上便是本文的全部内容，感谢阅读！
专栏作家
产品锦李，公众号：产品锦李（ID：IMPM996），人人都是产品经理专栏作家。不务正业的产品经理和他的产品设计。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。