系统型产品接口设计方法总结
文章简单总结了接口设计的一些方法,希望能够对你有所帮助。
现在社会都在将谈论“共享”,很多我们接触的APP中,要完成所有的业务流程多少都需要和第三方产品进行对接,使用第三方已完成的功能。
举个简单的例子:现在几乎所有的APP注册都是使用手机号进行注册,为了验证手机号为操作人本人所使用,都会发送一条短信验证码。这个时候,基本上发送短信的业务就使用到了第三方短信平台来完成。所以作为产品经理必须要了解,如何进行对接,要传什么信息给第三方平台,第三方平台处理完成业务后,所返回的信息我们应该如何处理等。
在此,我就简单的做个总结,让各位刚入行的产品经理们知道如何进行多系统对接。首先,从了解基本名称出发;其次,了解设计的方法;最后案例解说加深大家的理解。
一、了解名词及作用
1. 名词解释
- 软件接口:程序组件间对接的出入口。
- 页面跳转同步通知:如果一个进程在执行请求时,该请求需要一段时间才能返回信息,那么这个进程就会一直等待下去。通俗点就是有先后顺序,必须先完成前面事务才能做后面事务。
- 异步通知:进程不用等待可以继续执行下面的操作。背后信息传输,不分先后。
2. 接口作用
由架构师将整个系统架构搭建出来,各个子系统或者各个模块之间通过接口进行调用,可以让整个系统拓展性增强。
各个子系统或各模块之间信息传输必须要进行一定的安全验证,保证信息传输的正确性。
3. 接口的组成
接口常常成对出现,有请求参数和返回参数。
请求接口一般必须包括两个部分:基本参数、业务参数
- 基本参数:接口名称、身份认证参数(即对接的模块或系统ID、签名、密钥等)
- 业务参数:该接口所有提供的服务或者所要达到目标的业务信息。
4. 同步、异步一般传值情况
同步:主要作用于页面跳转,传值信息主要将页面所要处理的最关键信息传输即可。
异步:是为了强调给对接的模块处理业务信息,传值信息根据实际情况尽可能详细一些,但是必须和本接口设计的目标一致,不要传输太多无用的参数。
二、设计的方法及选择
1. 接口设计的方法
第一种:外部调用方call本系统的接口,同步返回请求成功,但实际操作是本系统延后去执行的,异步返回处理结果。
- 发起方:用户
- 优点:外部调用方不需要等待业务处理结果,可以进行自身其实业务处理。
- 不足:当外部调用方未能及时处理异步通知结果时,有可能会导致自身业务会存在一些风险或用户体验度不足。为减轻不足之处,此方式的接口设计,需要另外再设计一个查询业务处理结果的接口。
第二种:外部调用方call本系统的接口,业务处理完成后直接返回处理结果。
- 发起方:商户/外部调用方
- 优点:外部调用方必须等到本系统业务处理完成后才能继续进行自身系统的业务,可以避免存在遗漏的业务未处理。
- 缺点:外部调用方必须等待业务处理结果,前台用户也会看到等待页面,增加了用户的焦躁感。
2. 接口设计方式的选择
接口要为需求服务,在接口设计时的思考步骤:
- 回归产品的最初定位
- 设想业务场景,选择最优的用户体验方式。
- 根据最优的用户体验方式绘制业务流程。
3. 示例-广电公共账户充值
3.1.需求描述
- 为SP提供广电公共账户充值服务,该服务属于独立的功能模块。
- 用户进行业务订购,当公共账户余额不足时,需要充值账户余额后进行订购。
3.2.分析思路
1.定位:充值服务、独立功能模块。
2.场景设想:
3.场景选择:通过以上场景设想描述分析得出,场景二对于用户来说操作步骤会比较简单,可以最快的达到最初的需求目标。
4.接口设计方式选择:第二种方式
3.3.绘制业务流程
总结
在进行多产品系统对接时,在接口设计方法各有优劣势,采用何种方法进行设计最终还得回归到产品的特性,需考虑到产品运行的环境、产品定位、使用场景、团队技术水平情况等多方面考虑,去选择合适自身产品的方法。
作者:岚天,一位从前端开发转入产品岗的初级产品经理
本文由 @岚天 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自PEXELS,基于CC0协议
3.3绘制业务流程中
表述可能不准确,支付处理这一段,应该是从SP和乐众支付之间的调用返回?
不知道这样理解准确吗
产品经理搞接口就是不归路,提好需求,丢给架构师吧。不然搞到最后,产品写的都是接口文档,架构师在笑。
不能同意更多,之前去传统企业给移动做系统,妹的,北京总部的产品只做业务描述,我们成都的产品还要弄接口文档,用户自己业务都不确定,传统软件企业真是该被淘汰,产品界面丑,交互复杂,一点都不考虑用户体验,只为项目验收,而项目就是为了给领导看,实际都不用的功能。
同意,深有感受!
实用!