产品经理如何阅读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文档，是非常有必要的一件事情。无论是从产品设计的角度，还是对于和开发的沟通协调，以及产品经理自身修养的提高等，都会有不少的帮助，可以让你从更高的纬度去俯视整个产品。

也许，站的更高，真的能看的更远呢？