产品与技术结合解读：开放平台构建思路

随着互联 新零售模式的发展，营销已不是单一个体运营的时代。互联 的发展促使各个群体相互联合，使自身在互联 这个生态链上站稳脚跟。互相联合自然少不了平台的连接，今天和大家分享一下开放平台的构建思路。有些文章讲的过于产品，要么就是太偏向技术，今天我将产品与技术结合的方式来深入的梳理一下思路。

各大电商以及一些互联 应用公司，都建立了自己的平台，让更多的外部商户享受到平台带来的利益。如淘宝、支付宝、京东、开放了几百个不同的接口，外围商户可以根据需要创建不同的应用，为客户提供个性化的服务。

建设开放平台的意义在于，外部商户可以快速接入，投入很小的人工成本便可完成第三方接入能力。促使业务或应用快速上线。另外还可以提供一些基础服务，如果查询订单，交易、客户服务、对账、方便快捷的提供业务支持。并且可以很方便的管理第三方应用。

今天以某餐饮品牌为例，来梳理一下思路。某知名餐饮品牌为了推广自己的饮品，向其它渠道输出自己的的代金券。企业要生产自己的代金券，然响有需求的渠道分销，用户兑换这个券之后，便可拿到门店使用。假定该品牌也有自己的会员体系，不同等级的会员会享受不同的礼遇。

一、产品和开放对象

首先确定我们有哪些内容？

哪些内容是开放给外部商户的，这里我们把能开放给第三方的代金券、订单信息、会员信息、评论信息等统称为内容。

以某品牌为例：我们现在有自己生产折扣券和代金券，同时还有会员体系、会员产品，这里所说的会员产品比如月会员、年会员等。这些产品是可开放给外部商户进行商业行为的。

大概如下情况：

其次，考虑我们的平台为谁开放，谁可以接入到我们的平台？

这也是我们最原始的搭建开放平台的出发点。现在开放内容已经定了，哪些用户会跟我们的内容有关呢？分销商销售我们的券码、和充值会员产品、当然也可以销售会员兑换码。所以又要支持核销券码和充值会员。这里将会涉及到分销商、核销商。如果你与其它品牌进行联合会员，还会涉及到第三方会员的供货商，这里就不再提及了，思路都是一样。

这两种角色商户在我们平台涉及的交互主要有：

二、平台开放能力

现在已经确定我们有哪些产品，并且也确定了开放的对象。现在需要确定我们平台可以开放哪些能力。针对不同的业务开放的能力也是不同的，以上述业务场景为例：我们为分分销商提供充值、获取、查询、作废权益，同时提供券码消兑。

如果涉及到用户隐私信息或者需要支持其它app使用当前会员账号登录的情况，更安全的做法提供获取Token的服务。

外部商户如何才能获取到这些服务能力呢？我们需要支持商户自主创建应用，通过应用创建的方式提供货以这些接口服务。

三、平台服务能力

外部商入驻我们的开放平台，平台上将为外部商户提供一些基本的支撑能力。支付宝开放平台为了安全还专门为外部商户分角色创建子账号，用以管理不同的业务。这根据公司需要和能力提供更安全可靠的能力，根据业务范围，可为外围商户提供提交资质、应用管理、财务管理、申请和查看商品、查看交易流水、订单查询功能。

四、平台内部支撑能力

我们的开放平台当然不只是给外部人使用的，还有本公司的人员。所以还要确定内部人都什么角色使用这个平台。现在列出几种基本上都会有的，销售、运营、技术、法务、会计。

这里简单的列了几个模块，依据业务不同所涉及到的功能模块也各不相同，而且可能会涉及到更多的角色。

五、平台业务流程

六、商户入住

七、创建应用

为什么说是创建应用呢？而不是直接找到相关接口文档直接对接。

创建应用的好处在于：

应用、接口、应用类别三者关系：

1. 一个api接口可以属于0个或多个应用类别。比如一个作废的api，并不一定默认就开放给商户使用，由于涉及到结算，可能需要协议的支持才会开放，当需要开放时直接给相应的应用进行开放即可。而对于一个查询订单状态的api来说，默认可能属于多个应用类别，它属于公用api。
2. 一个应用类别可以包含0个或多个api接口，这种情况下当按照此类别创建应用后，需要人工添加与之关联的接口。比如很多情况下，不是所有商户都会按照你的开放平台标准进行对接，此时需我们就需要按一个不包含任何接口的类别创建一个应用，然后将按对方标准定制化开发后的api接口与应用直接绑定。
3. 一个应用只少且只能属于1个应用类别，为什么这么说呢，一个应用类别，就相当于一个抽象的应用，一个模子，而创建应用正好像实例化的过程，按照模子造东西的过程。
4. 一个应用类别可以包含0个或多个应用。当没有按照这个类型创建应用时，自然就不包含应用了，同理按这个应用类型也可以创建很多应用。
5. 一个api接口也可以属于0个或多个应用。如上述第1点，一个特殊的api需要手工开放给某个应用使用。
6. 一个应用也可以包含0个或多个api接口。如上述第2点，按照一个不包含任何api的类别创建应用时，这个应用也不会包含任何api。一些公用的api可以同时让多个应用来使用。

以上就是三者逻辑上的关系。在开放平台内部使用原型图呈现出来如下，仅供参考，模式是固定，思维是灵活的。

（1）api接口管理

将已部署到开放平台 关的api接口添加到开放平台。

（2）应用类别管理

创建应用类别，关联到api接口。

（3）应用管理

在平台内部，创建应用

创建应用，生成应用信息，主要是 appID、appKey、appSecret。创建应用时，需要指定应用类别、所属商户。我们自己创建应用的原因是，不是所有的商户都会主动的按照我们开放平台的标准api接入。但是我们依然可以按照开放平台的模式管理自己的应用，手动关联已定制开发好的api。

白名单：用来控制商户哪些地址可以访问我们的业务平台。

授权回调地址：一般用来单点登录，授权后通知到商户。

应用 关：商户回调接口API 关.

密钥：接口签名用到。

我们的api接口开发完后已部署到了开放平台 关，并且在平台上创建了应用类别，将接口与类别进行关联。商户在开放平台上注册完成后便可以按照类别创建应用了。

（4）在开放平台创建应用

那么，商户入驻开放平台后，商户按照某个类别创建应用，应用创建后便生成了一个appId,一个appKey，此时相关接口便与一个应用的实例进行了关联。商户便有了一个身份来访问这些接口，这里有必要提一下，一个appID,与appKey不一定是一对一的，根据业务的复杂度有可能是一对多的，用来申请不同权限的token。

有了身份之后我们还需要对身份进行鉴权，否则就相当于只有账号没有密码一样。所以在生就应用时，还需要生成 appSecret 。 appKey相当于账号，appSecret相当于密码，也就所说一个公钥和私钥。

有了这个关键数据，我们就可以通过已绑定的接口请求一个Token。这个token就相当于访问其它接口的一个临时令牌。短时间内有效的，当应用访问用衣隐私信息时，都必须带上Token。如果想深入了解token的获取和使用逻辑请查阅 OAuth2.0协议。

根据平台配置展示公开申请的应用：

此时商户的应用已经创建完成，商户侧可以根据指定的接口协议进行开发，所以我们还有必要在开放平台提供详细的文档说明。即前面提到的文档管理部分，内部技术人员对文档进行管理。

（5）财务管理

应用上架后，那么就可以进做正式业务了，在做正式业务之前，多数平台都需要商户预付一些款项，所以我们应该为商户提供一些线上付款功能，支付宝、微信、云闪付企业版均可以提供很好的支持。

如果没有提供线上的方式，商户在线下汇款后，平台应该支持提交付款信息和上传付款凭证的功能。以便财务人、运营可为商户认款到商户账户。根据需要还可为账户设置不同的账户，如现金账户、奖励账户等。涉及到款项时，平台还应该为商户提供一些预警机制，以免余额不足时影响业务。

（6）正式运营

商户付完款后，运营人员要为商户配置相关商品，如果你平台上的商品足够开放的话，也可由商户自己选择上线哪些商品。商品配置完后，商户便可以平台浏览到已开放的商品，以便上架到商户自己到平台。应用正式运营后，平台还应该为商户提供订单查询、交易数据查看分析等基本数据，方便商户进行对账，减少人工沟通成本。

小结

至此，已具备一个基本的开放平台的概念，核心思想主要是对开放接口、应用类别、应用的统一管理。以及业务为中心的涉及到运营、财务、等方面的功能支撑。实际正式的业务会比这复杂的多，重要的是在于构建思想。

欢迎各位互相交流学习！

题图来自Unsplash，基于CC0协议