文章目录
- 🍏 一、api 的定义：数据共享模式定义 4 大种类
- 🍖 二、api 使用场景：互联网时代，api 无处不在
- 2.1 sql 查询
- 2.2 数据传输
- 🍤 三、开放 api（OpenAPI）：开放双赢
- 🍳 四、api 的痛点和 eolink 的解决方案
- 🍕 五、小结
🍏 一、api 的定义：数据共享模式定义 4 大种类
作为互联网从业人员，api 这个词我耳朵都听起茧子了，那么 api 究竟是什么呢？
api 的定义，即应用程序接口（API：Application Program Interface）应用程序接口是一组定义、程序及协议的集合，通过 API 接口实现计算机软件之间的相互通信。
根据不同软件应用程序间的数据共享性能，可以将 API 分为四种类型：
- 远程过程调用（RPC）：通过作用在共享数据缓存器上的过程（或任务）实现程序间的通信。
- 标准查询语言（SQL）：是标准的访问数据的查询语言，通过数据库实现应用程序间的数据共享。
- 文件传输：文件传输通过发送格式化文件实现应用程序间数据共享。
- 信息交付：指松耦合或紧耦合应用程序间的小型格式化信息，通过程序间的直接通信实现数据共享。
🍖 二、api 使用场景：互联网时代，api 无处不在
在生活中，我们无时无刻都在使用 api，包含你打开的网页的同时，甚至触发了几百上千个 api，查询数据，系统之间交互，文件传输等等，api 都发挥了至关重要的作用。
2.1 sql 查询
小 A ：我写了一个 SQL，查询到数据库里的数据。
# 从全世界找到你
select * from the_world where someone like 'you';
# 查询结果
A very big pig
2.2 数据传输
小 B ：我打开一个 web 网页，页面的前端通过 https 接口获取到后端数据(拿到获取数据的 url 后，搞爬虫的小伙伴常用来下载数据)
🍤 三、开放 api（OpenAPI）：开放双赢
一般来说，内部 api 是非常机密的信息。但有时候，网站的服务商需要将自己的网站服务封装成一系列 API（Application Programming Interface，应用编程接口）开放出去，供第三方开发者使用。
如图所示，开放 api 主要分为 5 大类：
- 电信类
- 地图类
- 电商类
- SNS 类
- 微博类
从而吸引一些第三方的开发人员在该平台上开发商业应用，平台提供商可以获得更多的流量与市场份额，第三方开发者不需要庞大的硬件与技术投资就可以轻松快捷的创业，从而达到双赢的目的。
开放 API 是大平台发展、共享的途径，让开发者开发一个有价值应用，付出的成本更少，成功的机会更多。
🍳 四、api 的痛点和 eolink 的解决方案
api固然很强大，但在使用过程中，也存在许许多多的难题。
要分析 api 的痛点，不得不提到使用 api 的各个项目角色，通过以下的工作流程图，可以看到不同项目角色是如何参与到与 API 相关的研发工作中的。
- 后端工程师：约定接口、开发 api、编写文档、单元测试
- 前端工程师：约定接口、页面开发、Mock api、前后联调
- 技术管理者：技术评审、工期评估、管理文档
- 测试工程师：自动化测试 api、缺陷分析、问题反馈、输出测试报告
api 无处不在，无处不用，如果没有有效的 api 管理协作模式，不仅影响项目进度，大大增加开发成本，甚至出现被逼离职的尴尬境地！！！
在此，我总结了工作使用 api 的 5 个主要痛点，以及 eolink 的针对性解决办法!!!
| 序号 | api 使用痛点 | Eolink 的解决方案 | 适用岗位 |
|---|---|---|---|
| 1 | 不愿意编写文档，但又不得不写。 写接口文档是很枯燥乏味的工作。写好一个接口文档需要填写各个琐碎的字段。所以大家都更加愿意把时间花在编码上，仅草草的应付接口文档的编写工作。 | 根据代码生成文档 。Eolink 提供 IDEA 插件，可以基于代码一键生成 API 文档并同步到 Eolink 对应的项目中。接口文章除了提供展示标准的基础信息、请求参数、响应参数等字段后。还可以增加例如字段额外说明，标签，接口状态等信息。 | 后端工程师 |
| 2 | 接口文档的理解成本普遍比较高 前端工程师需要阅读接口文档来理解这个接口的出入参条件和业务能力。但接口文档往往要不描述信息简单，甚至有缺写漏写条件的情况，让人难以完全理解其接口。要不就是文档的模块信息混乱，无法快速理解接口内容。 | 简约但不简单的接口文档展示。 Eolink 的接口文档展示和主流的文档展示层次一致。分基础信息，请求数据，返回数据，返回示例等。不一样的是，对每个模块做了简约的补充描述设计。 | 前端工程师 |
| 3 | Mock API 编写麻烦 API 文档数据需要从 swagger 导入到对应的工具中，例如每个接口所有字段都要编写 Mock 规则等，整个流程还是比较麻烦。 | 智能 Mock。Eolink 提供市面最强的 Mock 体系，主要体现在可按不同的条件设置不同的 Mock 结果，以及提供智能的 Mock 配置方式。甚至系统可根据 API 文档自动生成标准的 Mock 规则，前端工程师无需编写，立即使用。 | 前端工程师、测试工程师 |
| 4 | 变更无通知同步 。因为前后端分离的开发很依赖文档的准确性和稳定性，若果后端工程师对接口进行了变更，但是在文档上无体现或者不通知前端工程师。会导致前端工程师沿着以前旧版本接口文档的内容进行 Mock 设计和前端页面开发。最终前后联调时才发现对不上，需要重新更改代码，造成了大量的返工。 | 变更实时通知和快速同步。Eolink 能提供接口文档变更快速通知的能力，无论是站内消息，还是第三方通讯工具，均能通过简单的配置搭建好通知渠道。前端工程师无需额外的配置调整操作，降低维护压力。 | 后端、前端、测试 |
| 5 | API 资产分散难以沉淀。 API 接口是业务代码标准化的价值实现载体，是重要的研发资产。但 API 接口文档往往分布散落在各个服务器上部署的 swagger，或者各个独立的在线研发文档中。难以以一个公司，或者一个部门的维度来对 API 文档进行统一归档管理。 | 多层级 API 管控 。 Eolink 的核心功能就是 API 接口文档仓库，提供对全公司的 API 文档进行多层级组织权限管控。可以解决 API 文档资产沉淀难的问题。 | 技术管理者 |
🍕 五、小结
互联网时代，api 无处不在，无处不用。
如何管理和使用 api，也成了研发、测试和项目管理者小白变大佬的必修课，今天的 api 科普和管理方法就到这里，see you！
体验地址：https://www.eolink.com/?utm_source=qyzzh&utm_medium=csdn&utm_content=zhpy01
