龙空技术网

To B产品经理如何设计接口类产品?

人人都是产品经理 150

前言:

而今小伙伴们对“聚合支付api接入”大约比较着重,各位老铁们都需要了解一些“聚合支付api接入”的相关资讯。那么小编也在网络上收集了一些有关“聚合支付api接入””的相关资讯,希望小伙伴们能喜欢,兄弟们快快来了解一下吧!

本文以被动请求接口为主,讨论如何进行对外系统接口的产品设计。一起来看看~

常见的To B产品有四类:

第一类为管理系统类产品,如CRM、ERP、BOSS平台等;第二类为办公系统类产品,如OA;第三类为商家端系统类产品,如给小B端用的商户系统;第四类为接口服务类产品,如聚合支付接口、人脸识别接口。

从产品形态上来说,前三类To B产品都具有用户操作界面,其设计原则和C端产品的设计方法有很大的重合,可以借鉴C端产品的设计方法进行产品设计,例如尼尔森十大可用性原则、简约设计方法等UE、UI设计方法就同样适用于前三类产品的页面设计。但第四类接口服务型产品没有操作界面,产品形态是以API接口存在,所以设计的方式与C端产品就会有很大的不同。

一、产品经理需要关注哪些种类的系统接口

系统接口分为内部系统接口(公司内部系统与系统间的接口,例如数据中台和业务系统的接口)和对外系统接口(提供给第三方调用的接口,一般都是基于HTTP/SOAP的协议接口,例如微信开放平台提供给小程序开发者的接口),内部系统接口对于产品经理来说无需过多关注,例如服务器端都会面向APP提供调用接口,产品经理只需定义好APP的功能即可,具体APP和服务器的传输交互会由开发工程师来定义。

对外系统接口包含:主动推送接口(主动给第三方发送信息)、被动推动接口(被第三方推送信息)、主动请求接口(主动请求第三方获取信息)和被动请求接口(被第三方请求获取信息)。

其中普遍的主动请求接口产品经理只需要能看懂就可以,不需要花费太多的精力提此类接口的需求,例如:自己公司采购了第三方的人脸识别接口用于业务中的身份验证,产品经理只需要提出在某某业务环节需要调用人脸识别功能即可,无须过多关注如何调用人脸识别接口。因此主动请求接口本文不做讨论,本文以被动请求接口为主,讨论如何进行对外系统接口的产品设计。

二、如何设计接口类产品

系统接口类的产品设计需要定义如下内容:输入内容、输出内容、业务异常处理方式、计费逻辑、响应速度、并发量、易用性等。

1. 输入内容

即第三方发送给我们的业务请求参数。产品经需要关注业务请求参数,同时明确参数是否可空,无需定义公共请求参数。例如数字证书在线生成接口(一般由CA公司提供的服务,应用调用该接口请求CA公司生成个人用户数字证书或企业用户数字证书),名称、证件号码、证件类别等信息属于业务请求参数中不可空的参数,没有此部分数据无法完成证书的生成;电子邮件、手机号等属于业务请求参数中的可空的参数,缺省此部分参数也可完成业务;应用ID、加密因子、加密算法等参数属于公共请求参数,公共请求参数内容无需产品经理设计,无需体现在需求文档中。

2. 输出内容

即接收第三方的请求后,经由系统处理后的业务返回参数。产品经需要关注业务返回参数,同时明确参数是否可空,无需定义公共返回参数。例如数字证书在线生成接口,第三方调用该接口后,系统需要返回cer格式的数字证书给第三方,cer格式的数字证书就是业务返回参数。输出内容同样需要明确参数是否可空,同时还需要明确是同步返回还是异步返回。

3. 业务异常处理方式

异常部分产品经理只需定义业务异常的处理方式,即产品经理对业务规则的要求。例如为保障图片质量,要求第三方通过接口上传的图片需要大于100K,则需要产品经理明确指出在此要进行图片大小检查,若不符合规则即抛出异常。系统异常(如参数错误、参数缺失等)无需产品经理来定义。

4. 计费逻辑

即接口如何向第三方计费。

计费逻辑常包含两部分:

第一部分是哪些情况下需要计费,哪些情况可以不计费,例如简项比对接口(通过接口上传用户的姓名和身份证号码,系统根据公安系统人口库判断输入的信息是否一致,接口输出比对一致、比对不一致、库中无此号码等结果),比对一致、比对不一致可以设置成计费,库中无此号码则可以设置成不计费。如果产品做得比较成熟的话,计费与否可以从后台管理系统中通过返回结果码自由配置。计费逻辑第二部分是需要明确计费方式,计费方式大致分为按次计费(调用一次接口收取一次费用)、阶梯计费(调用一次接口收取一次费用,但达到了一定使用量后单价有所下降)、按时间计费(包月或包年收费方式)。

5. 响应时间

即第三方从发出请求报文后,经历多久可以收到返回报文。通常接口的响应时间都是毫秒级的,但系统需要进行较大运算量的业务,响应时间可能会稍微长一些,例如OCR文字识别和音频识别接口,响应时间可能要达到几秒或几十秒,因为系统需要提取照片或音频中的文字内容。

6. 并发量

即系统支持同时请求接口的最大用户数量。通常并发量需求描述中会包含用户数量、响应时间、持续时长。例如聚合支付接口,请求高峰出现在中午12点到1点午餐时间,持续时长大概1个小时,对并发量的需求描述就可以按照500用户并发数,持续1小时,事务平均响应时间小于1秒来写。

7. 易用性

即接口对第三方来说容易读懂、容易使用,有基础开发背景知识的开发工程师就可以很方便的调用成功。通常接口类产品的易用性都是通过SDK(软件开发工具包,把接口封装成JAVA或PHP等语言的调用函数)和调用DEMO(示例代码)来实现,产品经理可以提出接口需要提供配套SDK(JAVA版本或PHP版本等)及调用DEMO的需求描述。

8. 其他

除了上述需求,还有一些不常用的业务需求产品经理可以关注,根据实际情况来判断是否需要写,例如系统每秒钟能够处理的事务数量(即TPS,系统吞吐量)需求;稳定性需求,即长时间运行一个比较大的并发量,观察系统是否稳定不宕机。

对外系统接口中产品经理还会关注主动推送接口(主动给第三方发送信息)和被动推送接口(被第三方推送信息),这两种接口的设计方法和上面所提的方法大体相同,但上面提到的都是非批量模式,这两种接口的需求需要体现推送是批量方式还是单次方式,例如给监管机构上报数据的接口就采用了主动推送、批量上报的模式,产品经理需要定义清楚上报内容,上报频次,上报异常处理方式。

本文由 @产品工具箱 原创发布于人人都是产品经理,未经作者许可,禁止转载。

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

标签: #聚合支付api接入 #phplpush #php推送