上一个章节我们已经初步认知了API，现在我们继续了解API，通过阅读，分析，理解，再到应用系统的讨论。
前期准备
在正式接触API前我们需要进行一些前期准备，主要分为账户准备，基础认知。
前者主要包含提前到OTA开发平台注册，获取到沙箱环境、正式环境的相关参数，准备好技术文档，沟通流程建立（群组沟通、工单沟通）、费用结算计划。
后者包含简单从全局的角度来评估可能用到的接口类型和个数，例如订单推送金额是客人支付金额还是扣点后金额来决定数据解析的形式，并且当有多个接口可以获取同一参数时如何最大化利用，寻求最高效的解决方案。
对API有基本的认知。例如，数据获取或交互是post还是get,是需要订阅还是全部统一回调，这一点非常重要会影响到整体的设计或优化。例如，某平台的订单支付消息是需要自行订阅的，如果不订阅则需要自行设计过滤逻辑来固定时间筛选已支付订单（资源浪费），但另外一个平台却又是统一的回调指定地址。此时，因为地址只有一个但是回调数据确设计N个接口，我们就需要根据数据结构的差别对同一个回调地址的不同数据进行解析后用于不同的功能上。
此外数据响应同步/异步的取舍，也直接影响到后续的数据处理与数据补偿。例如，有库存限制的产品通常采用异步返回的处理模式，既能保证响应速度也能保证响应正确率。
示例A：所有垃圾都被扔进了一个垃圾桶，我们需要一个人躲在后面根据相关参数进行垃圾分类：干垃圾、湿垃圾、厨余垃圾等等，这个就是一个回调地址的多种数据结构解析。
示例B：考试交白卷，老师马上给你打一个0分；考试全部乱选，老师先给你说等我对一下答案，稍后还是给你打一个0分；虽然结果都一样，但是前者同步返回确认结果，主要应用于100%确认结果的，后者是异步返回，需要有一定内部处理机制。
API解析
此时进入了最关键的环节，即充分去了解API文档。此处的了解并不是技术上的认知，而是将API与业务功能上的融合。
此时，我们将分为三个阶段去深入解析API。
阶段一
接口描述：了解接口的主要用途与范围，注意关键点例如收费模式、申请资格。
请求方法与请求参数：方法主要为get与post;请求参数力求以最简单的数据获取更多的内容，例如订单号、产品编号、交易流水号就可以获取到整个结构信息。
响应参数：参数的响应其实并不是简单的成功、失败，更多的其实包含了一些中间状态，比如某平台产品更新接口可能会返回处理中，那这样的数据需要二次核验是否更新成功。
错误代码：错误代码解析也是提高生产力的优化点，一般来说错误代码为纯数字，其表达的意思也是比较技术的例如超时，无响应等，此类报错直接抛出将会让业务人员一脸懵，适当对错误代码优化可能大大提高用户体验，例如我们对超时重试的温馨提示为：App发送超时,系统将自动发起重试，可忽略此条消息。
阶段二
Jason响应的重要性，为什么我会提这个问题？
这个不是开发关注的吗？
大错特错，作为一个优秀的产品经理，具备一定的报文阅读能力是很有必要的。
阅读报文的好处：
在需求的前期，功能的不完善会导致数据缺失。此时，我们并不能在脑海里快速构建一个完整的三位立体的结构。面对技术化的字段名称，一个个去理解其含义与用处，既耗时又容易遗忘。
如果我们与开发小哥通力合作，快速的调通接口，获取到原始数据，犹如将枯燥的文档化为了一条条鲜活的数据。
此时，将报文数据转化为jason后放置到解析网站，立等可取——换一种方式来阅读文档，更加灵活。对比字段的表述与实际展示，更容易理解字段所表达的功能点。
2）快速熟悉掌握对方的API结构
Jason阅读下的另外一个好处是可以以每一个节点收起或展开报文，类似于脑图的操作下。我们可以快速理解对方的API结构，例如出行人与订单的关系、附加信息与订单关系是存在于订单级别还是SKU级别还是出行人级别等，方便我们对照自己的订单结构进行快速解析。
3）有具体的实战场景去穷举各种可能
做API对接最忌讳啥？面对文档空想各种可能，自己主观揣测返回可能值；对方答疑最讨厌什么？并不是实时，可能要等很久，怎么什么都问，不是文档里面有吗？
自己怎么解决？
跟开发一起调通API后就可以进行数据模拟了，凡是拿不准的结构，拿不准的返回值都可以根据业务演示一遍，获取到准确的返回便于一次性解析到位，穷举各种场景，避免遗漏。
阶段三
通过上述研究对API文档有了大概了解会就需要进行结构化的总结与分析，着重两个相反方面的总结。
1）功能的匹配度
大致对自己需要解析的数据进行评估，目前使用的接口是否可以实现功能？匹配度是多少；因为不同的系统之间肯定存在差异，我们有必要提前评估两个系统的兼容程度来确认人力的投入。
例如目前的解析难度有多大？
首先，看使用的接口数量，力求最少的接口解决最多的问题，接口数量增多则势必增加响应速度（这里并不是严格只接口响应速度，而是对接口之间的调用逻辑相互叠加后增加了复杂度，内部判断延长增加了各种超时响应的可能性）。
其次，还应该提前做好映射准备，做API的势必离不开映射，映射能很好解决不同系统间相互兼容问题的，简单的理解如下。
儿子：妈，明天早上有重要的事，八点钟一定要叫醒我。
妈妈：好的，那你不要睡懒觉哦。
……
妈妈：快起床，都已经八点半了。
儿子心急火燎收拾完冲出家门，一看才七点半不到。
在这个梗中，我们可以认识到在儿子的自身系统中的八点，在妈妈的系统中自动映射成了七点了。虽然没有直观的可视化，但是我们可以明显感受到通过两个系统的传递高效的实现了叫儿子起床的任务。
最后，因为涉及商品、订单的参数还是比较多的，相关映射一定要提前做准备，在产品结构设计中就要全盘考虑，并在开发阶段准备好数据与映射关系。
2）结果差异化
差异化=1-匹配度
前文说了匹配，这里我们说差异，每个系统都有自己不同于其他系统的特征，这对于我们来说将是非常棘手的问题，因为一旦差异化的出现也就表示系统对接过程中遇到问题，要么更换接口曲线救国，要么就要针对差异化给出自己的解决方案。此时整个API的核心本质凸显：解决差异，实现统一。
例如，我们在某平台对接的时候发现其订单的补差价（购买后需要再补一笔钱）功能没有相关接口通知，那即使有补差订单接口，无法知道订单号，明显逻辑有问题。我们采取的方案分为两条线，第一条向平台反馈，提出问题（截止笔者发稿时已经解决），第二条自身因为补差通常由商家向客人发起，所以我们自己是知道的，所以当客人补差完成时我们设置一个通知按钮来替代。
归纳总结
就跟写作文一样，往往到了最后我们需要进行上下文的总结，来再次确认主题，呼应主题。
我们一般从三个方面来进行。
与对方技术支持进行沟通处理
经过上面的梳理，我们势必会对API文档里面的相关报文或者表达意思有异议，此时可以向对方技术支持提问来搞定，并且可以测试一下沟通流程，固定流程。
大家觉得不就是沟通而已，为什么还要这么正式？
简单思考一个问题，为什么很多开发平台要么严格走工单这种效率低的沟通方式？
要么走及时沟通工具快速解决问题呢？
工单沟通既可以统计自身处理效率，也可以为提问方建立小型“知识库”，便于后期自查。
沟通工具便于前期平台搭建时与种子用户、核心用户交流，快速响应，弊端是反复问反复回答同一类型问题。所以，大家在沟通环节一定要注意，例如工单一定要进行提前量，例如我方开发可能需要较多时间排查问题时，可以先提交工单节约时间，提高效率。
与我方技术探讨
产品经理不光是功能的缔造者，更是交流的桥梁。当我们获取到整体的API框架时，在评审前后我们势必还是需要与开发非正式的探讨一些我们关系的话题。
例如，数据接入后的可视化问题，数据不可能永远不“见光”，可视化需要考虑的是数据展示的友好化，业务的连续性；前者强调如何将枯燥的数据进行便于理解的展示。
例如，当我们向某平台推送产品时，我们在可视化页面会展示很多字段，A字段的值固定且灰色显示，这个表示我们只能阅读而不能修改，B字段的值有下划线，鼠标移动有光标闪烁表示可以修改；后者可理解为我们对API解析的数据不是为了存储，而是为了进一步的利用，例如当我们把订单获取到我们的页面展示后还要红色字体提示最晚确认时间，便于客服进行下一步处理。
与我司业务探讨
技术层面的沟通完毕后，我们需要有一个交代，也就是对业务的回复。
告知其整体项目的难度，便于其有一个心理预期，其次还需要表明自己需要的支持，例如需要联系对方沟通、配合准备数据等。
技术侧的理解
在API解决方案成型前，我们需要站在技术的角度上与开发人员反复沟通，宣讲我们的思路，推动我们的方案，让开发人员理解我们需要实现的系统大概雏形，以及产品经理的解决方案。避免脱离业务来写代码。
此时我们再回到上一节讲过的重点即系统的整体架构设计。后续我们也会以全新打造自研ERP为例来进行举例讲解。
业务方想要的是快速推送产品，并及时确认订单——>通过对接各个平台产品API接口推送产品信息、通过订单API接口解析订单信息并形成交互——>在梳理过程中发现后期的收付款财务模板被业务方忽略了，需要我们一并解决（隐藏需求）——>坚持内外不相扰的策略，需要有一个中间库处理平台来处理输出标准信息到ERP实现内外数据互通互融。
整体系统框架
此时，再来阅读整个系统，我们可以清晰的梳理出单个平台的处理流程以及整个系统的后期可拓展性。
坚持“殊途同归”的思想，外部平台无论有什么特征，都到中间库进行标准化作业后输出符合自身ERP要求的数据进行处理即可。
对于新系统可以具备强大的可拓展性，对外可轻松接入其他平台，对内可完美兼容自身订单；对于已存在系统，不影响原系统下仅需小成本改造。
实战案例
后面三篇文章，笔者将分别对三个OTA平台（小海豚、小佩奇、小蜜蜂），各自摘取关键的API信息，从产品自动推送、订单自动化流转、财务自动对账三个方向实战讲解。
#相关阅读#
OTA实战分解（1）：快速阅读API及场景应用
