产品经理如何绕开API的坑?

作者: whereyougo | 来源:发表于2017-06-08 23:18 被阅读526次

    刚接触产品工作时,对接口,即API的概念一片空白,不理解接口是什么?更别说能看懂接口文档了,在接口上踩了很多坑:

    比如这些场景,

    场景1:

    开需求会,提了新的需求,开发说,你这个需求太复杂,光接口就有20几个,按照排期根本做不完。我一脸懵逼,虽然表示怀疑,却无力反驳。

    场景2:

    好不容易理清楚需要几个接口,提了新的需求,开发说,你把读写接口搞混了,不可能一个接口实现你说的这个功能。

    场景3:

    其他部门向我提了两个接口需求,我找到开发完成接口后交付给需求方,结果需求方说接口的响应时间和并发数达不到要求,得推倒重做!!

    究竟接口是什么呢?又如何看懂接口文档?接口性能对功能的影响是什么呢?如何在产品需求中理清接口呢?

    一、API是什么?

    API是应用程序编程接口,如何理解呢?

    API就好像是一个传输数据的通道,入口需要请求数据,就好像是通关密码,而出口需要返回结果。

    接口的使用方不需要关心接口是如何实现的,他只关心能不能拿到接口最后的返回结果。

    接口的提供方需要定义接口请求参数、响应内容等,还需要关注接口的性能,是否能满足高并发的调用,接口的稳定性如何……

    二、如何看懂接口文档

    以一个真实的接口文档做范例,:

    接口一般分为以下几个部分:

    1、接口描述:

    简单描述接口的逻辑和作用

    2、接口地址

    接口的正式url和接口测试的url,需求方通过调用接口url,获取响应内容

    3、请求方法

    一般来说,接口最常见的请求方法为GET和POST两种方式,Get是用来从服务器上获得数据,而Post是用来向服务器上传递数据。也可以简单理解为读接口和写接口。通过这两种方式,实现对数据的增删查改。删查改本质都是写的动作。

    4、请求参数

    即需要请求的字段名的名称和规则:

    请求的是哪些字段,字段的类型是什么,是否必填字段等等

    5、响应内容

    接口返回的字段名称和规则

    注意:

    很多开发往往不会把所有的字段罗列(其实是懒)

    比如这个文档,你可以很明显的发现,响应内容中缺少了数据写入状态这个字段,但是在后续实例中,是包含has sucess这个字段的。

    6、错误代码

    对接口的错误用代码进行归类,以便能快速找到错误原因,解决问题。

    7、实例

    实际调用时的响应的内容

    三、接口性能

    不同的业务场景对于接口性能的要求是各不相同的,在做接口之前,一定要开发讨论,正在做的接口是否能满足调用的需求,未来是否会增加新的调用方,扩展性如何?不然就会出现,前文中场景3的悲剧。

    接口如何优化,pm可以不用了解,由开发去把关,但我们需要知道接口性能的核心指标。

    1、接口响应时间、并发数

    接口响应时间:

    从请求端发送一个请求开始,到接收到响应结果所经历的时间。

    并发数:

    指同时访问服务器站点的连接数。

    实际的并发数并不总是符合我们的期望,需要压测或者实际使用才能知道接口能支持的最大并发数是多少。

    响应时间越短,多线程并发数越高,接口性能越好。

    不是所有的业务场景都需要“最好”的性能,满足业务场景即可。

    2、线程

    一个程序有多个进程,一个进程有多个线程。

    如果把上课的过程比作进程,那么每个学生就是一个线程,CPU是老师,教室是内存,他们共享教室,即线程共享进程的内存空间。每一个时刻,只能一个学生问老师(CPU)问题,老师回答完毕,接着回答下一个学生问题。

    三、如何在产品需求中理清接口

    1、如何拆解接口

    大家牢记一句话,接口分读接口和写接口。

    不管多复杂的需求,涉及到多少个接口,其本质就是读接口和写接口。

    举几个例子:

    (1)游戏点券充值接口

    (2)获取用户列表接口

    (3)评论标记精选接口

    (4)投放卡券接口

    其中,1、3、4都是写接口,因为都涉及到写入相关数据的动作。2是读接口,涉及读取和查询数据。

    这样来看,接口貌似很好理解,有写入数据的就是写接口,有读取数据就是读接口

    但是在理产品需求时,有的时候常常理不清楚功能对应的接口,解决办法很简单,就是拆解需求。

    比如我们要设计一个身份证实名认证的功能,需要满足一个身份信息只能实名认证一个账号,如果用户认证了数据库里已经存在的身份证,那么会提醒用户身份信息被占用。

    首先,我们需要拆解需求:

    (1)实名认证是针对未实名的用户,已实名过的用户无需再进行实名,所以我们需要一个查询接口

    (2)还需要一个写接口,让用户去写入身份信息或修改身份信息

    (3)因为一对一的要求,所以还需要一个查询数据库是否存在已有的身份信息

    (4)某些用户实名后,可能会因为各种理由,想解除实名,所以还需要一个删除的接口

    2、接口的请求和响应字段

    (1)接口需要请求哪些字段,是否必填,字段的格式有什么要求吗?

    比如上面提到的(3)查询数据库是否存在已有的身份信息,请求字段为会员ID,姓名,身份证号,均为必填字段,姓名首先必须得纯中文,身份证号也必须满足位数要求。

    (2)接口需要返回哪些字段,是否必填,字段的格式有什么要求吗?

    原理同上

    四、测试接口的神器

    推荐一个测试接口的神器-postman,百度搜索即可下载,通过postman可以自行测试接口,下图是我用了豆瓣的接口,进行测试,不仅能看到接口的body,cookies,Headers信息,还可以看到接口的响应时间、数据大小信息:

    五、几个值得注意的事项

    除了功能和逻辑外,还需要注意接口的异常情况

    (1)前端做好交互,提示用户,以免因为接口不稳定,导致线上bug,而前端缺乏引导,导致用户不能正常操作,影响用户体验。

    (2)有的场景可以准备备用接口,之前负责一个通过地理定位签到的产品,是通过用户的定位和本地库里的定位去匹配,返回签到是否成功,产品上线后却总是出现用户明明已经在指定定位地点,却无法签到的情况,引发用户投诉,后来排查发现,本地库的定位存在偏差,后续引入了外部接口:高德接口,在访问本地数据无法匹配的情况下,调用高德接口,很好地解决了定位不准这个问题。

    相关文章

      网友评论

      • JasmineWei:谢谢~获益良多:+1:
      • e31fdcc2d618:接口眼
      • 书呆鱼:这个比较6
        属于接口普及
      • 我在睡觉:(2)对于某些重要的功能,还要做好两手准备,准备两个接口,一个接口挂掉还可以用另外一个接口。

        这个是啥?
        whereyougo:@我在睡觉 公司买的外部接口不稳定,又找了另外一家供应商的外部接口备用
        我在睡觉:你自己做的项目用过备用接口?
        whereyougo:@我在睡觉 备用接口,实现同样的功能

      本文标题:产品经理如何绕开API的坑?

      本文链接:https://www.haomeiwen.com/subject/ssqxqxtx.html