为什么第三方平台对接越来越复杂？

前段韶光在产品经理的互换群里碰着一位小伙伴揭橥的迷惑：

刚好笔者之前也对接过其余一家第三方电子条约平台，本文就以电子条约为例，磋商一下：为什么第三方平台对接越来越繁芜？

笔者注：为了便于阐述不雅观点和确保内容的易读性，文中涉及的流程均做了一定程度的简化，不能作为对接第三方电子条约平台的对接参考，请读者把稳分辨。

我之前在《新手产品经理必学技能接口文档知识》中讲过，在设计开拓产品的时候，产品须要用到某些功能，但这些功能的实现对付现有的团队而言，可能缺少业务领域的上风，或缺少技能领域的上风，亦或两种领域的上风都明显不敷，因此每每须要通过对接第三方平台来实现，像上文那位小伙伴提到的“电子条约”，由于涉及严格的备案和鉴权，在海内，能够做这个业务的公司屈指可数，因此多数公司的产品只能选择对接有资质的第三方平台。

但在对接第三方平台的过程中，暴露出的问题越来越明显，便是明明只须要实现一个非常大略的业务，但是接口方供应的接口非常多，让产品经理以为对接起来非常繁芜，那么，到底是什么缘故原由造成了这样的局势呢？

要想解答这个问题，首先要从对接方的角度，看看最大略的对接流程该当是怎么样的，再来剖析为什么接供词给方没有办法按照最大略的流程来做。

一、最大略的对接流程

从对接方的角度，以上流程虽然对接了4个接口，但实名认证和签署只需通过链接跳转到对接平台的页面进行操作，因此其核心对接步骤只需两步：

签署人通过对接平台进行实名认证后，业务平台发送须要签署的文件到对接平台，签署人到对接平台供应的页面进行签署；签署完成后，业务平台获取已签署的文件保存到自身做事器中。

那么为什么对接平台不能供应这样一个大略的流程给到对接方，而是每个环节都要弄出一大堆接口出来，紧张是基于以下考虑。

二、为了场景的兼容性

以天生待签署文件为例，有两种场景，一种是业务平台直接天生待签署文件上传到第三方平台；另一种则是业务平台上传模板到对接平台，然后往模板中添补内容并天生待签署文件，两者的大致作业流程如下：

通过以上作业流程可以创造，无论是直接上传待签署文件，还是通过模板天生待签署文件，最开始的时候都须要做一个上传的动作，两者只是上传的文件不同而已，因此，在设计接口的时候，获取文件上传地址和上传文件这一步每每可以设计为2个接口，而非4个接口，系统只需根据上传的场景在接口参数中标记清楚当前文件是属于待签署文件还是模板即可，比如用“file”表示待签署文件，用“template”表示模板。

因此，把接口拆得更细，能够兼容更多的场景，同时能够提高部分接口的复用率，如果根据业务流程把一堆接口封装成一个接口，那么上文提到的两个场景中，将有部分接口内容属于是“重复造轮子”。

三、为了流程的灵巧性

在电子条约签署流程中，有一个环节叫做“签署流程归档”，归档的观点是表示文件已经签署完成，不能再对该文件发起签署，我们想象的归档流程和真正的归档流程分别是这样的：

是不是觉得莫名其妙又多此一举，明明一个接口能够搞定的事情，偏偏还要多调用一个归档接口之后，电子条约平台才进行归档，但如果我见告你以下两种场景，你该当就能够理解这个设计的意图了：

平台须要对电子条约署名进行人工审核，审核通过才归档，审核不通过哀求签署人重签；须要多人签署的文件，等到所有人都签署完成之后才创造漏了一个签署人，此时须要将该签署人加上去，并让该签署人签署。

因此，在平台设计接口的时候，就已经考虑到各种不同的场景，以是将一些主要环节的决策权交还给业务平台去决定，从而使得流程更加灵巧。

四、必不可少的异步关照

在签署条约过程中，我们想象中签署流程和真正的签署流程分别是这样的：

我们想象中的签署流程是一挥而就的，然而真实的场景中，从平台发起签署流程到签署人进行签署，或多人签署的场景等到末了一人完成签署，都是须要等待一段韶光的，这段韶光可能很短，也可能很长，但系统不可能一贯在那里等着（loading），因此，就有了一个“异步关照”的观点，异步关照可以理解为某个流程的完成须要一定的韶光，在这段韶光内，业务系统无需做任何处理，等到该流程完成后，对接平台会通过其余一个接口来关照业务系统，业务系统再进行后续处理，这个接口，便是异步关照接口。

以上文的签署流程为例，假设一个多人签署的流程，在全部签署人签署完成后进行归档，其流程是这样的：

五、不可忽略的商业性

除了上文提到的缘故原由，拆分接口对付平台的商业性而言，也有一定的上风，比如上文提到的签署流程中，签署人须要先通过平台进行实名认证，拆分实名认证接口，等同于将实名认证的业务与电子条约签署的业务进行分割，如果有客户只须要实名认证的做事而不须要电子条约签署业务，则可以将该业务独立开来进行收费。

以是，现在你知道，为什么第三方平台对接越来越繁芜了吧？

以上便是本文的全部内容，感谢阅读！

专栏作家

产品锦李，公众号：产品锦李（ID：IMPM996），大家都是产品经理专栏作家。
不务正业的产品经理和他的产品设计。

本文原创发布于大家都是产品经理，未经容许，禁止转载。

题图来自Unsplash，基于CC0协议。

该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。