还记得5月，人生第一个产品经理面试，面试官问你知道api吗，当时脑袋一懵。事后，决定一定要把它弄清楚。在查询资料后发现，API确实对于产品经理来说那是相当重要：1.对技术理解更深刻，结合已有新的接口，让产品有更丰富的可行性，并降低工作量。2.更好地预估开发工作量，制定合适产品方案
文章将从API介绍，分类，API文档内容和案例四个方面进行介绍。
1.API是什么
全名：Application Programming Interface 中文名：应用程序编程接口
百度百科释义：API是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
看到这你是不是和我一样有点懵,这也太抽象了。于是我又找了一些相关文章和他人的探讨。
最后找到一个比较清晰易懂的解释：
“简单的说，开放接口是一个抽象的概念，直接听名字就知道他是为了连接而开放的入口，以让别人的程序能够调用你的程序数据。就像你的电脑、手机有一些USB接口，也可以说是开放了接口，有了这些接口别人就可以用他来做插U盘或充电等功能。只是说API不是硬件接口，而是程序软件接口罢了。”
举个例子，蓄水池与水泵。
如果把提供接口的一方，比作蓄水池，那么池子里装的就是一些封装好的数据啊函数之类之类。这时候如果蓄水池想把他的水，分享给其他人，他就需要在自己身上造个出水口，这个出水口就是所谓的接口。
2.API的种类
a.根据响应的机制可以分为同步、异步接口：
同步接口：A系统请求B系统接口之后，必须获得B系统接口的响应后才会执行下一步操作。
例如：登录操作的时候调用第三方平台接口（如微信）进行登录，需要跳转到微信进行验证并返回验证结果后，才能登录成功。
异步接口：A系统请求B系统接口之后，不需要等待源系统返回结果就可以进行下一步操作。
例如：在滴滴打车之后，司机点击结束行程后，不需要等待银行付款成功之后再开始下一个订单。因为此时滴滴已经验证过司机、乘客的银行账户或者支付宝账户，确认了双方交易的合法性就可以结束订单。
这时，我们看到的是我们已经付款成功（其实银行可能还没扣款），而滴滴后台会将这笔交易流水传给银行，在银行验证后再进行扣款、付款操作。
b.根据接口的触发形式可以分为分发、订阅接口
分发接口：A系统产生新数据的时候就分发给B系统（也可以是多个）。
例如：电商网站后台的客户管理系统，在产生了一个新的黑名单客户的时候，就会将数据分发到订单、推荐等等各个系统，以便及时拦截这部分客户的订单。
订阅接口：B系统在需要的时候调用A系统的接口进行数据订阅。
例如：用户在股票交易软件中查询银行账户余额的时候才会调用银行的余额查询接口，而股票交易软件自身不存储这个数据。
3.接口文档内容
如何调用接口，需要通过接口文档进行说明。其主要内容有以下几点：
接口描述：这个接口是用来干嘛的，以及相关的规则；
接口地址：以网址的形式展现，你通过发送请求给这个网址来对接口进行交互操作；
请求方法：常用的有post（写接口）和get（读接口）两种方式，读接口即查询相关数据，写包括修改，增加或删减数据。（请求指令可以用很多种语言来写，一般有curl、php、python、java等等）
注：我们通常说的http传输形式最基本的方法有4种，分别是GET，POST，PUT，DELETE。我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查，改，增，删4个操作。GET一般用于获取/查询资源信息，而POST一般用于更新资源信息。不过对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。
请求参数：请求该接口时，需要提供的参数，参数属性包括名称、类型、是否必填、描述等；
返回参数：接口正常响应后，返回的内容；
错误代码：接口请求失败后，返回的错误代码。
4.api案例展示
这里采用的是@PMnote前辈最初所负责的加油卡虚拟充值服务，通过合理调用接口，简化用户操作界面，解决了终端机不能输入汉字，而充值需要输入姓名问题。
应用平台是在终端机上，它与PC和手机不同是具有一下几个特征：
1.屏幕大，相应的按钮与文字都比其他平台要大，触屏的敏感度不如手机，操作的精准度不如PC，所以要做到尽量少的输入。
2.不能输入汉字。
3.根据用户使用终端设计的场景，核心用户为中老年人，会在相对固定的场所，以站立的方式在屏幕前操作，会有工作人员协助操作，可能会遇到后方排队的现象，所以操作尽量直观简化，防止用户出现焦虑等情绪。
带着这些特点与场景，那么进行一次产品设计吧。
首先根据业务部门提出来的需求，只做中石化的充值卡，并且是以固定面额进行充值，这是一个大前提。之后就去了解了一下，目前PC或手机上加油卡充值的大概操作流程。
具体的操作流程
输入卡号——确认卡号——选择金额（输入金额）——输入手机号——接受验证码——确认并支付——到网点圈存
好像输入的地方有点多，想一想根据终端机的特性，能不能进行简化呢？带着这个问题，再回头来看看接口文档与加油卡相关的接口都有哪些。
经过查看发现，关于加油卡充值接口有两个，一个是充值接口、一个是卡号信息查询接口。
信息查询接口主要功能就是输入19位的卡号后，返回给我们卡主的真实姓名。因为我们都知道中石化的卡办理是需要身份证实名认证的，所以这个功能实际上能够帮助用户确认自己输入的卡号是否正确。
好，我们记下这个功能以及他能解决的问题。
再看加油卡充值接口。因为一些原因这里就不给大家贴图了。不过可以说一下这个接口需要的参数都有哪些，包括，cardid这个参数来决定你是需要任意金额充值，还是固定面值的充值。另外就是卡号，加油卡类型等参数。
不过值得注意的是我发现在接口里有个参数需要输入手机号码与持卡人姓名。他们是否是必填项呢？接口没有写清楚。而且终端机不能输入汉字的规则，如果要输入姓名，这将是一个不能完成的任务了啊，除非接口方更改规则。
似乎产品走到这里，有些地方不太清晰了，那么我们要做什么，当然是沟通喽。
持卡人手机号是否必填？
是的。
用来做什么的呢？
中石化会给这个手机号发送充值成功的短信。
好的，谢谢。
那持卡人姓名呢？
这个是辅助信息，不是必填项
好的。
这时候顾虑都没有了，接口貌似能够顺利的使用啦。
功能都确定了之后，想想是否能简化原有的步骤呢。记得做产品的时候业务部的同事提议让用户输入两次卡号来确认，因为通常都是这样做的。这时候就能用到那些写PM文章里的一句话，需求需要分析，不能拿过来解决方案就用。
如果输入两次卡号是为了让用户确认自己输入是否有误，那么我们可不可以利用卡号查询接口，来给用户返回姓名来解决这个问题呢？
实际上根本要满足他的需求是，让用户知自己输入的卡号无误。
如此在产品设计上，我就只采用了一次输入卡号的形式，让接口返回我真实姓名就好了，而且让一个人在终端机上输入两次19位卡号，那也是一种折磨。
功能确认，操作流程确认了。因为业务流程沿用了之前公司设定好的流程这里就不再赘述。剩下的工作就是画原型图了，注意，在画原型的时候最好加入input的一些规则限制，调用哪些接口，正确与错误的提示都是什么？有什么异常状态，需不需要做友好提示等等。这些交互说明都对前端开发和技术开发是必须要的。
这样就完成了一次通过调用接口来实现产品功能、设计的一个全过程。
参考资料（点击可直接进入）
[1] PMnote,《利用「接口」做产品时我们该如何思考？》，人人都是产品经理
[2] LinKiD,《产品经理，你要懂点API接口知识！》，人人都是产品经理
