做产品助理之后接的第一个产品就与“API接口”有关。刚做的时候，稀里糊涂，后来各种喷过后，才慢慢理解了“接口”这个东西。都说产品只需要“了解”技术就可以，不需要自己会写。所以不知羞耻的我对这东西也只知表皮啦。做到懂得基本原理，会看，会用，就好了。

如果你和我一样是个技术盲，那么我们要先来扫盲一下了。

恩。有点复杂

简单的说，开放接口是一个抽象的概念，直接听名字就知道他是为了连接而开放的入口，以让别人的程序能够调用你的程序数据。就像你的电脑、手机有一些USB接口，也可以说是开放了接口，有了这些接口别人就可以用他来做插U盘或充电等功能。只是说API不是硬件接口，而是程序软件接口罢了。

这里给大家举个例子，蓄水池与水泵。

如果把提供接口的一方，比作蓄水池，那么池子里装的就是一些封装好的数据啊函数之类之类。这时候如果蓄水池想把他的水，分享给其他人，他就需要在自己身上造个出水口，这个出水口就是所谓的接口。

这时候水泵出场了，水泵很需要这些水，他找来了一个水管用来把水抽出来，这时候水泵发送一个指令，蓄水池就会放出一点水。同样，今天你想要水，明天你想要果汁，都需要通过指令来命令蓄水池。

这样的一去一回，就完成了一次对接口的交互。

可能说的不是很严谨，但是你能懂个大概意思就可以了。

大概的原理我们懂了。那如果拿到一个接口文档我们该如何来阅读呢？

一个比较专业的文档都会写上各种补充说明辅助你理解，比如接口使用的协议、格式、接口应答返回的数据格式等等。

拿一个手头的接口文档给大家看看，比较正规的文档格式：

小白大呼看不懂这些奇怪的文字，那么下面就教你如何看懂这些参数。

一般接口包含以下几个内容：

接口地址

顾名思义就是接口的地址，以网址的形式展现，你通过发送请求给这个网址来对接口进行交互操作。

请求方法

请求指令可以用很多种语言来写，一般有curl、php、python、java等等，而与我们合作的接口方提供的就是curl的方式。

如下图，就是典型的curl的GET请求形式。

很多产品都会听到技术说这个用POST传输，那个用GET传输，那么什么是POST和GET呢？

我们通常说的http传输形式最基本的方法有4种，分别是GET，POST，PUT，DELETE。我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查，改，增，删4个操作。

GET一般用于获取/查询资源信息，而POST一般用于更新资源信息。不过对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。

所以一般我们只会看到GET和POST两种。两者的区别在于get多用于查询，而POST多余用对资源进行修改的操作。比如一般的天气查询，账号金额查询都以GET形式传输，比如登陆信息的传输就会用到POST。

更直观的区别去两者的话，GET请求的数据会附在URL之后，以?分割URL和传输数据，参数之间以&相连，如：xxxx.ha?userid=PMnote&userpws=123456&version=6.0。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。而POST把提交的数据则放置在是HTTP包的包体中。

请求参数

即传输参数的时候要带的一些参数，一般文档中会用表格的形式清晰的说明。当我向接口发送携带请求参数的请求时，都要携带什么字段，规则是什么。如下图：

返回内容

返回内容一般会以json或是XML的形式返回。

上图就是以XML的形式返回的。

像上面贴出来的这种接口，还是比较好阅读的。如果我们发送userid和userpws，就是用户名和密码给接口，接口就返回给我们err_msg为空，则说明正确，retconde也返回1说明也成功了。

如果错误则retcond返回空，如果出现其他错误就可以查询具体的错误代码提示内容了。ret_leftcredit则返回了352328.97的数字，这就是这个账户中的余额啦。

所以可以看出该接口主要是为了查询余额而用，使用了GET方式，传过去用户名和密码，返回正确或错误，如果正确则显示余额，错误显示错误信息。

是不是很容易理解啦。

错误代码

最后是错误代码，一般都会附在接口文档的最后，如果在测试或是上线后，可以根据返回接口查看问题。也可以在设计产品时将错误的状态显示在前端。

知道了接口的原理，看到了接口的各种参数和规则。

接下来就到了实战了。

接口是如何应用在产品设计当中的呢？

请先记住，接口决定功能，接口决定功能，接口决定功能。重要的事情要说三遍。

笔者在第一次碰接口的时候就傻傻的去照抄了其他网站的一些功能和验证方法，没有做好最初与接口方和技术的沟通工作，结果在评审的时候就被喷的体无完肤了。

“你确定接口有这个功能吗？” “这个接口是实现不了这个功能的。”

所以在产品设计之初就要先透彻了解手中的接口文档中的接口是否具有你想要的功能。

下面以一个加油卡充值来举个实战案例。这是我最初所负责的加油卡虚拟充值服务。

应用平台是在终端机上，它与PC和手机不同是具有一下几个特征：

带着这些特点与场景，那么进行一次产品设计吧。

首先根据业务部门提出来的需求，我们只做中石化的充值卡，并且是以固定面额进行充值，这是一个大前提。之后就去了解了一下，目前PC或手机上加油卡充值的大概操作流程。

具体的操作流程

输入卡号——确认卡号——选择金额（输入金额）——输入手机号——接受验证码——确认并支付——到网点圈存

好像输入的地方有点多，想一想根据终端机的特性，能不能进行简化呢？带着这个问题，再回头来看看接口文档与加油卡相关的接口都有哪些。

经过查看发现，关于加油卡充值接口有两个，一个是充值接口、一个是卡号信息查询接口。

信息查询接口主要功能就是输入19位的卡号后，返回给我们卡主的真实姓名。因为我们都知道中石化的卡办理是需要身份证实名认证的，所以这个功能实际上能够帮助用户确认自己输入的卡号是否正确。 好，我们记下这个功能以及他能解决的问题。

再看加油卡充值接口。因为一些原因这里就不给大家贴图了。不过可以说一下这个接口需要的参数都有哪些，包括，cardid这个参数来决定你是需要任意金额充值，还是固定面值的充值。另外就是卡号，加油卡类型等参数。

不过值得注意的是我发现在接口里有个参数需要输入手机号码与持卡人姓名。他们是否是必填项呢？接口没有写清楚。而且终端机不能输入汉字的规则，如果要输入姓名，这将是一个不能完成的任务了啊，除非接口方更改规则。

似乎产品走到这里，有些地方不太清晰了，那么我们要做什么，当然是沟通喽。

这时候顾虑都没有了，接口貌似能够顺利的使用啦。

功能都确定了之后，想想是否能简化原有的步骤呢。记得做产品的时候业务部的同事提议让用户输入两次卡号来确认，因为通常都是这样做的。这时候就能用到那些写PM文章里的一句话，需求需要分析，不能拿过来解决方案就用。

如果输入两次卡号是为了让用户确认自己输入是否有误，那么我们可不可以利用卡号查询接口，来给用户返回姓名来解决这个问题呢？

实际上根本要满足他的需求是，让用户知自己输入的卡号无误。

如此在产品设计上，我就只采用了一次输入卡号的形式，让接口返回我真实姓名就好了，而且让一个人在终端机上输入两次19位卡号，那也是一种折磨。

功能确认，操作流程确认了。因为业务流程沿用了之前公司设定好的流程这里就不再赘述。剩下的工作就是画原型图了，注意，在画原型的时候最好加入input的一些规则限制，调用哪些接口，正确与错误的提示都是什么？有什么异常状态，需不需要做友好提示等等。这些交互说明都对前端开发和技术开发是必须要的。

这样就完成了一次通过调用接口来实现产品功能、设计的一个全过程。