产品经理需不须要懂技能接口文档？这个问题我以为就跟问产品经理需不须要懂技能是一样的，而我的建议是，须要懂，但只须要有限度地懂。本日我结合之前的一些项目履历，以对接电子***中的开具***接口为例，分享产品经理怎么学会看懂技能接口文档。
本文因此产品经理理解的角度去解释和解构接口文档，可能在技能角度未必是精确的，如果有卧底的开拓大佬，还请勿喷！
一、什么是接口文档
要学会看接口文档，首先得明白什么是接口文档，接口文档的浸染是什么。
随着开拓技能的发展，逐渐发展成为前后端分离的开拓办法，大略讲便是前端开拓工程师和后端开拓工程师各自开拓属于自己范围的内容，末了通过 api 接口来进行前后端信息的通报，而接口文档便是记录各个不同业务用到的 api 接口以及它们所通报的信息的技能文档。但这种文档一样平常是内部用的，因此可以说是纯粹为了开拓做事，产品经理基本打仗不到。
后来，随着业务形态的发展，在某些业务领域或技能领域有较强上风的公司会通过***自身能力来得到发卖的收入，比如支付能力、***流媒体能力、AI 能力等，使得购买的公司能够以最快的办法实现相应的能力，而实现这种能力的办法之一，便是通过开放 api 接口来进行对接，接口文档可以让产品经理和开拓工程师快速对接业务和技能。
这么讲可能有点抽象，举个例子，比如我现在有一个商城产品，须要利用移动支付，但是我自己没有金融牌照，不能做在线收款的业务，而某公司有金融牌照，可以开拓在线支付的功能并进行在线收款，该公司通过开放干系的技能接口，商城只须要按照接口对接完成，由该公司来进行代收代付，即可完成在线收款的功能，当然，该公司在此过程中可能会收取相应的用度，这种是属于有业务领域上风的类型。
其余一个例子，比如商城须要做一个在线直播的功能，但是目前公司没有在线***流媒体等技能的专业开拓职员和技能积累，而某公司则是在这方面有着多年的履历和深厚的技能积累，因此我们可以购买接入该公司的做事，快速实现在线直播的功能，这种，则是属于有技能领域上风的类型。
二、接口事情事理
以下图片可以帮助我们理解接口的事情事理：
我举一个例子，比如【接口开放方】开放了一个接口，接口名称为【你好】，接口哀求供应【姓名】作为参数，并返回【某某某，你好】的内容，个中【某某某】是要求接口时供应的【姓名】。
接口的交互用户是无法感知的，以是须要在用户端处理内容的输入和输出，比如在网页上放一个输入框，让用户输入姓名，假设用户输入【李雷】，点击确认，这个时候，【接口要求方】要求【你好】这个接口，并通报姓名【李雷】，接下来就会收到【接口开放方】相应回来的信息【李雷，你好】，此时再将收到的这句话通过弹窗之类的形式在用户端显示出来，这样就完成了一次接口的调用。
【接口要求方】无需理会【接口开放方】内部的实现方法，只需关注收到相应后如何处理相应即可（如上方例子中的将收到的信息通过弹窗形式显示出来），而处理相应一样平常涉及业务干系，以是须要产品经理参与，因此产品经理看文档的时候，须要知道，某个接口是为了实现什么功能（比如上方的“你好”接口会返回问好的笔墨），须要供应什么参数（如上方的“姓名”），会相应什么参数（如上方的“某某某，你好”的信息），收到相应后要怎么处理（一样平常跟接入方的业务有关）。
三、常规接入流程
这里讲的是常规的接入流程，不代表所有平台都因此这样的办法接入，以下是接入流程示意图：
不是拿到接口文档就可以接入，刚刚提到，接供词给方可能会按照某种办法来收取一定的用度，以是接口的利用肯定是须要在接口开放方的授权下才能进行，以是在完成商务会谈之后，一样平常接供词给方会哀求接入方在他们平台注册账号，并通过技能手段给接入放分配干系署名参数。
署名参数有两种浸染：
以是署名参数可以理解为是带有身份信息的通畅证，有了署名参数，才能够正常要求接口，并且每次要求，接供词给方都能知道是谁发起了接口要求。
四、怎么看接口文档
刚刚讲的都是一些纯理论的东西，接下来我以某电子***平台的接口文档为例，讲讲如果我所在的平台须要增加一个开具电子***的功能，在收到接口文档之后，要怎么看。
这是接口文档的目录，在收到文档之后，建议先看先容，这里面一样平常会涉及到当前对接的这个产品的解释、实现功能、适用场景等，产品经理须要结合自身产品的业务剖析要对接的产品的功能和适用场景是否符合公司想要实现的业务。
接下来是【调用办法】中的【署名方法】，这个须要分情形，如果你的平台是自己对接，自己利用，作为产品经理可以不用看这块，但是如果你做的 SaaS 系统，你的平台可能会入驻多名商户，每名商户都须要去接供词给方平台注册并供应署名参数，你不可能每次有新入驻的商户就让开发工程师往数据库里加数据，最合理的办理方案便是在后台设计一个商户管理功能，在商户管理功能中增加署名参数的填写，这个时候，作为产品经理你就必须得知道，这个平台须要供应哪些署名参数，从而支撑你完成这块功能的设计，比如这个***平台的署名参数哀求供应以下4个参数：
那么你在设计时，就须要供应相应参数的输入。
接下来是“主菜”，在 api 列表中，一样平常会按照不同的业务功能划分不同的接口，并以对应的业务描述来命名接口，因此，我们如果要设计开具***的功能，须要先找到对应的接口：
点击对应接口后，就可以看到接口的详情，以下是作为产品经理须要关注的几个点：
口解释：这里面一样平常会有一些比较主要的信息，一定要先仔细阅读，有些产品经理一上来就跳过接口解释的内容，直接看接口参数，然后碰着问题办理不了，一贯在原地转圈，结果创造人家已经在接口解释中说了会碰着什么问题，是什么缘故原由，怎么办理。
要求参数：这个是产品经理须要重点关注的内容，这里面涉及到在调用这个接口的时候须要供应什么参数，这些参数每每都是用户输入的，因此产品经理须要根据所需参数在用户端网络相应的信息，如以下关于开具***接口的部分要求参数：
这里面我们要关注的，紧张是【是否必填】以及【描述】，描述中会解释这个参数是什么，有什么哀求，这里一定要区分好哪些参数是技能须要的，哪些参数是业务须要的，产品经理要重点关注业务参数，如果不清楚参数的用场，可以找接供词给方的供应帮助。
有一些相应的校验须要产品经理在用户端网络信息的时候就做好哀求，防止提交给接口的参数是不符合哀求的，这样会摧残浪费蹂躏网络资源（每次要求都须要等待回答，如果多次考试测验失落败，会让用户以为体验不好），乃至摧残浪费蹂躏金钱（有些平台会按照接口要求的次数收费，要求一次扣一次用度）。
相应参数：这是要求接口之后，接供词给方回传给我们的参数，一样平常会包含状态和对应的参数，如下是开具***的相应参数：
但是这里有点奇怪，我们如果申请开具电子***，至少要把电子***的文件给我们吧，不然我们怎把文件给用户，这时候我们仔细看一下，原来开票的接口是通过异步关照我们的，这里就须要区分什么同步什么是异步了。
一样平常我们提交之后，可以立时反馈给我们的便是同步关照，比如这里的状态，见告我们已经提交成功了或者已经开过票了。而异步关照是说，我们要求的这个接口须要的一部分内容，须要等待接供词给方处理，处理完之后再见告我们结果，比如这里，开具***申请提交成功，但是开票平台须要同步税务局的系统进行开票，这里须要有一个处理的韶光，要等它处理完之后再见告我们结果。
我们可以找一下，创造接口文档中确实有一个【开票接口异步关照】的接口，点开拓现这里返回的参数就非常多了，包括开票的状态，电子***开票成功后电子***的url等，收到相应的相应信息之后，我们须要只须要处理对应的信息即可，比如前端可能须要更新开票的状态，或者显示电子***的***入口等。
以上是个人的履历之谈，希望能够对刚入行的产品经理学习阅读接口文档有一定帮助，感谢阅读！
本文由 @产品锦李 原创发布于大家都是产品经理，未经容许，禁止转载。
题图来自Unsplash，基于CC0协议。
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。
