刚接触产品工作时，对接口一片空白，不理解接口是什么？API是应用程序编程接口，如何理解呢？API就好像是一个传输数据的通道，入口需要请求数据，就好像是通关密码，而出口需要返回结果。通过这两种方式，实现对数据的增删查改。每一个时刻，只能一个学生问老师问题，老师回答完毕，接着回答下一个学生问题。2是读接口，请求方式为GET，涉及读取和查询数据。
刚接触产品工作时，对接口（API）一片空白，不理解接口（API）是什么？更别说能看懂接口文档了，在接口上踩了很多坑。接下来，将结合自己的亲身经验与大家分享。
比如这些场景：
场景1：开需求会，提了新的需求，开发说，你这个需求太复杂，光接口就有20几个，根本做不完。我一听就蒙了，虽然表示怀疑，却无力反驳。
场景2：好不容易理好接口，提了新的需求，，开发说，你把读写接口搞混了，不可能一个接口实现所有功能。
场景3：其他部门向我提了两个接口需求，我找到开发完成接口后交付给需求方，结果需求方说接口的响应时间和并发数达不到要求，得推倒重做，oh my god！
究竟接口是什么呢？又如何看懂接口文档？接口性能对功能的影响是什么呢？如何在产品需求中理清接口呢？这篇文章将解答你的疑惑。
一、API是什么？
API是应用程序编程接口，如何理解呢？
API就好像是一个传输数据的通道，入口需要请求数据，就好像是通关密码，而出口需要返回结果。
接口的使用方不需要关心接口是如何实现的，他只关心能不能拿到接口最后的返回结果。
接口的提供方需要定义接口请求参数、响应内容等，还需要关注接口的性能，是否能满足高并发的调用，接口的稳定性如何……
二、如何看懂接口文档
以一个真实的接口文档做范例，给大家讲解：
接口一般分为以下几个部分：
1、接口描述
简单描述接口的逻辑和作用
2、接口地址
接口的正式url和接口测试的url，需求方通过调用接口url，获取响应内容
3、请求方法
一般来说，接口最常见的请求方法为GET和POST两种方式，即读接口和写接口。通过这两种方式，实现对数据的增删查改。删查改本质都是写的动作。
4、请求参数
即需要请求的字段名的名称和规则：
都是哪些字段，字段的类型是什么，是否必填字段等等
5、响应内容
接口返回的字段名称和规则
注意：大部分开发往往不会把所有的字段罗列，只会列出比较重要的字段。
当你发现，接口文档中没有你需求的字段，别着急找开发，可以看下实例中，有没有需求的字段。
比如这个文档，你可以很明显的发现，响应内容中缺少了数据写入状态这个字段，但是在后续实例中，是包含has sucess这个字段的。
6、错误代码
对接口的错误用代码进行归类，以便能快速找到错误原因，解决问题。
7、实例
实际调用时的响应的内容。
三、接口性能
不同的业务场景对于接口性能的要求是各不相同的，所以在做接口之前，一定要开发讨论，正在做的接口是否能满足调用的需求，未来是否会增加新的调用方，扩展性如何？不然就会出现，前文中场景3的悲剧。
接口如何优化，pm可以不用了解，由开发去把关，但我们需要知道接口性能的核心指标。
1、接口响应时间、并发数
接口响应时间：
从请求端发送一个请求开始，到接收到响应结果所经历的时间。
并发数：
指同时访问服务器站点的连接数。
可以进行简单估算，如果响应时间<200ms，1s=1000ms，1000/200=5，如果有10个线程，秒并发>50，一分钟就可以连接超过50*60=3000次，一个小时就可以连接超过3000*60=180000次
如果有20个线程，那秒并发可以超过100。
实际的并发数并不总是符合我们的期望，需要压测或者实际使用才能知道接口能支持的最大并发数是多少。
响应时间越短，多线程并发数越高，接口性能越好。
不是所有的业务场景都需要“最好”的性能，满足业务场景即可。
2、线程
一个程序有多个进程，一个进程有多个线程。
如果把上课的过程比作进程，那么每个学生就是一个线程，CPU是老师，教室是内存，他们共享教室，即线程共享进程的内存空间。每一个时刻，只能一个学生问老师（CPU）问题，老师回答完毕，接着回答下一个学生问题。
三、如何在产品需求中理清接口
1、如何拆解接口
大家牢记一句话，接口分读接口和写接口。
不管多复杂的需求，涉及到多少个接口，其本质就是读接口和写接口。
举几个例子：
- 游戏点券充值接口
- 获取用户列表接口
- 评论标记精选接口
- 投放卡券接口
其中，1、3、4都是写接口，请求方式为POST，因为都涉及到写入相关数据的动作。2是读接口，请求方式为GET，涉及读取和查询数据。
这样来看，接口貌似很好理解，有写入数据的就是写接口，有读取数据就是读接口
但是在理产品需求时，产品小白常常理不清楚功能对应的接口，解决办法很简单，就是拆解需求。
比如我们要设计一个身份证实名认证的功能，需要满足一个身份信息只能实名认证一个账号，如果用户认证了数据库里已经存在的身份证，那么会提醒用户身份信息被占用。
首先，我们需要拆解需求：
- 实名认证是针对未实名的用户，已实名过的用户无需再进行实名，所以我们需要一个查询接口
- 还需要一个写接口，让用户去写入身份信息或修改身份信息
- 因为一对一的要求，所以还需要一个查询数据库是否存在已有的身份信息
- 某些用户实名后，可能会因为各种理由，想解除实名，所以还需要一个删除的接口
其次我们需要明确接口传输的字段
2、接口的请求和响应字段
（1）接口需要请求哪些字段，是否必填，字段的格式有什么要求吗？
比如上面提到的（3）查询数据库是否存在已有的身份信息，请求字段为会员ID，姓名，身份证号，均为必填字段，姓名首先必须得纯中文，身份证号也必须满足位数要求。
（2）接口需要返回哪些字段，是否必填，字段的格式有什么要求吗？
原理同上
3、最后啰嗦一些注意事项
除了功能和逻辑外，还需要注意接口的异常和错误情况，
（1）前端做好交互，提示用户，以免因为接口不稳定，导致线上bug，而前端缺乏引导，导致用户不能正常操作，对产品颇多怨言。
（2）对于某些重要的功能，还要做好两手准备，准备两个接口，一个接口挂掉还可以用另外一个接口。
本文由 @丹小喵 原创发布于人人都是产品经理。未经许可，禁止转载。
