产品经理不需要深入地去了解各个接口的实现原理，毕竟术业有专攻，但是了解什么场景应该使用什么样的接口还是很有必要的，可以方便更好地对外提供数据服务。

刚成为产品经理的时候常常听到开发吐槽：“这产品经理啥都不懂，这个需求那么多接口，开发都够呛还要联调，居然就排这么点开发时间，出了什么问题我可不负责！”

每次听到这样的吐槽总会一脸懵逼——什么接口？什么联调？我又做错了什么？

后来自己做过开发之后，开始了解到：在系统层面上，除了看得到的页面功能，还有很多隐藏在页面功能之下的接口。

这篇文章就简单总结一下：我眼中的接口是什么样的？以及，为何要学习API接口知识？

什么是接口？

API接口：应用程序接口（API：Application Program Interface），是一组定义、程序及协议的集合，通过 API 接口实现计算机软件之间的相互通信。

打个比方，如果我开了一家银行，开放了存/取款的服务。普通储户通过手上的支票想取走存款，必须先找到对应的【位置】，也就是正确的银行、正确的柜台。

按照银行规定的【支票格式】填写好，那么就可以凭这个“支票”里拿走钱。

另外，柜台是有限的、来取钱的客户可能会很多，因此也就需要客户【取号排队】，一个接着一个有序的进行取款服务。为了安全和服务质量的考虑，银行柜台需要有【反馈机制】，如果客户支票填写有误、或者支票过期了，需要告诉客户回去重新填写。

【位置】：系统对外发布的API地址，包含了IP、端口、API名称等信息。

【支票格式】：这个接口的数据传输规范，比如：SKU只支持9位长度的字符串数据，库存只支持16位长度的数字，如果传参格式不对，那么就会启动【反馈机制】。

【取号排队】：接口的“消息队列”，消息队列的主要特点是异步处理，可以减少请求响应的时间和解耦。想象一下，如果取钱的人不【取号排队】而是一哄而上涌上柜台，柜台还能提供正常的服务吗？

【反馈机制】：接口中的返回参数，为了保证对方能够正常获取所有的数据，不至于因为数据异常之类的原因导致数据丢失，在发现异常的时候，需要告知对方发生了什么异常，为什么无法获取到这个数据，对方就会根据这个反馈做出相应的调整，或者重新发起请求、或者放弃这种数据。

注：开发人员口中的“联调”，简而言之就是两个系统的开发人员之间对这个接口调用成功与否、数据能否正常获取等场景进行测试。由于接口联调涉及到跨系统的开发人员之间配合，所以一般需要在正常的开发时间之外预留出一段时间给到开发人员进行联调。

接口的类型有多少种？

上面只是用一个比较通俗的例子对接口的原理进行说明，实际上接口的类型有很多，下面会根据不同的接口类型讲讲各种类型接口之间的区别：

1. 根据响应的机制可以分为同步、异步接口：

同步接口：A系统请求B系统接口之后，必须获得B系统接口的响应后才会执行下一步操作。

例如：登录操作的时候调用第三方平台接口（如微信）进行登录，需要跳转到微信进行验证并返回验证结果后，才能登录成功。

异步接口：A系统请求B系统接口之后，不需要等待源系统返回结果就可以进行下一步操作。

例如：在滴滴打车之后，司机点击结束行程后，不需要等待银行付款成功之后再开始下一个订单。因为此时滴滴已经验证过司机、乘客的银行账户或者支付宝账户，确认了双方交易的合法性就可以结束订单。

这时，我们看到的是我们已经付款成功（其实银行可能还没扣款），而滴滴后台会将这笔交易流水传给银行，在银行验证后再进行扣款、付款操作。

2. 根据接口的触发形式可以分为分发、订阅接口

分发接口：A系统产生新数据的时候就分发给B系统（也可以是多个）。

例如：电商网站后台的客户管理系统，在产生了一个新的黑名单客户的时候，就会将数据分发到订单、推荐等等各个系统，以便及时拦截这部分客户的订单。

订阅接口：B系统在需要的时候调用A系统的接口进行数据订阅。

例如：用户在股票交易软件中查询银行账户余额的时候才会调用银行的余额查询接口，而股票交易软件自身不存储这个数据。

产品经理了解接口有什么用？

以上不同类型的接口分别有不同的使用场景，个人认为产品经理不需要理解各种接口的实现原理，但是要了解什么场景应该使用什么样的接口，以便更好地对外提供数据服务。

个人看来，了解接口有以下几个好处：

1. 明确各个系统之间的数据流转，特别是功能系统的产品经理，只有在知道了功能设计的目的、需要对外提供什么样的接口服务，需求设计阶段才能够考虑得更加全面；
2. 掌握开发总体工作量，而不局限于功能；另外，在安排项目计划时能够考虑到与周边系统联调的时间，计划安排才会更加合理；
3. 识别项目中的关键风险点，特别是一些关键接口、数据量大需要进行大数据压测的接口，需要尽早安排联调和测试，并且对周边配合的项目提出要求。

产品经理如何写接口文档？

在度娘就可以找到不少现成的接口文档，可以参考腾讯开放平台上的API列表，这里简单总结几个要点：

1. 声明接口字段和返回参数，字段需要声明是否必填、字段类型、长度以及处理规则；
2. 声明接口预估的数据量大小、调用频率等，以保证开发时考虑到接口的健壮性；
3. 声明接口的异常处理方式，如失败的数据是否重发、重发次数等等。

在之前的产品设计过程中，还出现过配合系统双方的产品经理为了谁应该来写接口文档而争执过。后来定了一套标准，个人认为是比较合理的，供大家参考：

原则1：一般是由数据的需求方来编写接口需求文档。

原则2：如果该接口是一个分发接口，则由数据的提供方来编写接口需求文档。

总结：

好了，说到这里，已经把我个人这些年工作中所接触到的API接口简单介绍了一下。由于本人一直是做后端产品经理，因此对于前端的接口涉猎不多，不了解差异有多大，以上内容仅供后端产品经理参考，也希望大家能够对文中的一些错误及时指正。

另外，作为一名大数据的产品经理，大数据如何利用接口对外提供服务？后续总结出自己的一套方法论后再分享。

本文由 @LinKiD 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议