产品经理如何阅读API文档

*近在公司内部负责两个微信小程序项目,于是将许久没有接触的开发文档阅读工作又捡了起来。

很多人也许要问了,产品经理一定要读开发文档么?这个不是技术童鞋要做的事情么?

客观地来说,大多数时候你要是基于自己的平台去开发产品,那么是不需要在开发文档上花费多少心思的;但作为一个第三方平台的产品经理(尤其如微信、支付宝等),阅读平台的API文档,则是相当有必要的,也可以说是产品基本功吧。

那么,产品经理究竟该如何来阅读API文档呢?

什么是API

API,全称是Application Programming Interface,即应用程序编程接口,我们日常中习惯简称为“接口”。其实,接口这个词大家应该不会陌生,比如我们平时比较常用的“USB接口”,就是用来存储和传输数据用的;那什么是API呢,API事实上是在内部预先定义了函数,能够使开发人员无须明白API内部实现的机制,就能够实现某一个功能。

比如说你要实现一个手机注册的功能,那么相应地后台工程师就需要提供一个手机注册的接口,前端开发人员在调用接口实现功能的时候,只需按照既定的规则进行请求即可,不需要去理解该功能的实现逻辑。有了这么一个机制,就使得开发人员间的协作变得非常简洁、高效。

所以,你可以简单地理解为“接口决定了功能”。

那API究竟是用来干嘛的呢?我的理解是,API其实是大自然的搬运工。如何理解这个“搬运工”的概念,其实就是指搬运互联网数据,因为API的本质就是根据调用者的输入内容来返回一些其他内容,不就相当于把数据搬来搬去么(这个搬运工的比喻是不是很形象)。

API文档的结构

通常来说,一份API文档内会包含多个API的信息,单个API的信息通常包括以下内容:

接口描述:这个接口是用来干嘛的,以及相关的规则;

接口地址:以网址的形式展现,你通过发送请求给这个网址来对接口进行交互操作;

请求方法:常用的有post和get两种方式,一个是读接口(常用get)一个是写接口(常用post);

请求参数:请求该接口时,需要提供的参数,参数属性包括名称、类型、是否必填、描述等;

返回参数:接口正常响应后,返回的内容;

错误代码:接口请求失败后,返回的错误代码。

小程序开发文档

阅读API文档的好处

这个恐怕是大多数产品童鞋的疑惑,就是产品经理去阅读开发文档,究竟收益在哪里?从我个人的经验出发,也许会有这么几点收益:

1、对技术理解更深刻,让产品更有想象力

试想这么一个场景,如果你是小程序的PM,但是又不去阅读开发文档,可能带来的悲剧结果就是,微信开放了许多小程序的*新能力,但是你却不知道如何应用到你自己的产品中去;或者,即使知道大概有那么一回事,却不清楚具体可以做的操作细节有哪些,在自身产品中的应用场景在哪里,而往往产品细节和场景又是那么地重要。拿我自己实操的一个案例来说,就是因为当时没有阅读开发文档,所以误以为不能获取微信群的名称,只能获取到微信群的id,导致*后在产品设计的时候没有给用户更好的绑定群信息感知的体验。

说的直白一点,没有新技术就没有新的想象力(别问我想象力是什么)。

2、更好地预估开发工作量

长时间阅读API文档,可以对接口有更加深刻的认识,那么在和开发评估开发工作量的过程中,也是有帮助的。因为很多时候,产品和开发对新旧的理解不同,所以会造成这样一种现象:新的功能不一定需要新的API,相似的功能可能需要重新做一个新的API。如果产品经理在熟悉了开发文档之后,就能大幅减少这种情况的发生,评估一个新的功能开发工作量的时候,不会仅仅站在产品设计的角度(这两个功能不是差不多么,所以基于之前的接口应该很快就能上线吧),还会站在开发的角度(噢,这里的确要两个接口来实现),这样也更有利于产品和开发童鞋的和平共处。

3、锻炼产品抽象能力

事实上,接口本身就是个非常抽象的事物,大概在很久很久以前,有一个人跟我说过一句话,接口都是可以抽象起来进行复用的,但是前端却是千变万化的。嗯,其实一个厉害的产品经理,如果真的非常熟悉接口的话,他是可以做到像搭建乐高积木一样,来通过现有的接口搭建产品的。听说在腾讯内部,腾讯会将大系统尽量拆分成功能单一的模块,在架构上尽量使用插件式的设计,高度解耦,并且会将业务逻辑服务化,比如将摇一摇、漂流瓶等都做成服务,供微信、QQ等开发团队调用,这里调用的就是API。

总结

总的来说,对于第三方平台的产品经理,熟悉官方API文档,是非常有必要的一件事情。无论是从产品设计的角度,还是对于和开发的沟通协调,以及产品经理自身修养的提高等,都会有不少的帮助,可以让你从更高的纬度去俯视整个产品。

也许,站的更高,真的能看的更远呢?