如何通俗解释 API ？顺便聊聊 API 的未来趋势

大家好，我是秦一， Eoapi 的 PM&开发。在跟非开发同事沟通时，时常发现他们对 API 相关的概念还不是很懂，我想借此文谈谈我对 API 的理解，希望文章对你有所帮助！

一、什么是 API？未来趋势？

API 是什么？日常生活中，有很多类似于 API 的概念，例如电脑、手机接口。

如果你要将手机里的数据传输给电脑，你可能会需要拿一根数据线连接电脑和手机的接口，在这里 API 是一种通信手段。

1.1 API 是一种在软件系统间通信的方式

API 中文全称是应用编程接口，从纯技术的角度去描述 API，就会说 API 是一种在软件系统间通信的方式。

这时候我们就会用 HTTP API、Websocket API 去描述它。

其实就像我们数据线有安卓接口、苹果接口，而 HTTP、Websocket、TCP 只是不同的通信协议而已。

接下来看看和有关 API 的趋势，先看三个数据。

1. IT 团队整体花在 API 相关工作上的时间超过了50%;

2. 全球可统计的外部 API 数量在 2014 年已经突破100亿个（不包括企业内部和系统内部调用的 API）；

3. IBM 认为全球 API 经济规模在2018年已经突破2.2万亿美元。

这些数据都表明，API 行业正在飞速发展。

1.2 推动行业发展的因素

经过这几年我们的观察和思考，会发现推动 API 行业发展的因素有两个，科技的进步与数字化转型。

科技的进步，随着公有云基础设施的不断完善、微服务架构的普及让系统不断拆分，API 数量呈现爆发式增长。

1.2.1 微服务是什么？

微服务是一种通过多个小型服务组合来构建单个应用的架构风格。

听起来有些技术，所以我拿现实中设计产品做为例子。

产品初生的时候，很简单，很轻量。

慢慢的用户多了起来，我们疯狂迭代，功能也多了起来。

如果所有功能都加到同一个产品上，功能越来越多，每个功能满足多种用户的需求越来越难。

所以最后拆分成极速版和基础版，产品变得更灵活了，加功能也方便，也能满足不同用户的需求。

所以微服务是通过多个小型服务组合来构建单个应用，拆成小的服务后，系统的服务复杂度是不是低了，可以自己管自己了，也可以在每个服务用不同的语言，让不同的团队负责不同的服务等等。

好，那微服务和 API 有什么关系呢？

所有服务都在一个应用里面的叫单体架构。

当它里面的每个业务逻辑都被分解为一个微服务，就变成了微服务架构。通常情况下，这些客户端并不能直接访问后台微服务，而是通过 API 网关来传递请求。

这些微服务间沟通交流的方式就是 API ，微服务架构下服务多了，API 自然就多了。

1.2.1 数字化转型

推动行业发展的第二个因素是数字化转型。

近年来数据的价值被逐步发现，企业和政府都在追求数字化转型，从我们国家政策就可以看出来。主席也说要以数字化转型驱动变革。

所以在这些背景下，越来越多的场景需要通过 API 进行数据的传递和交换，通过 API 发挥出数据最大的潜能。

1.3 API 是产品

这几年来，行业对 API 的理解已经发生了许多的变化。从纯技术的角度来看，API 是一种在软件系统间通信的方式。

而实际上我们平时常说的 API 实际上指的是 API 背后提供的服务或数据，例如短信接口、天气接口。

跳出技术的思维去看，API 正在从一个技术工具转变为数字资产。

原本我们通过代码和 API 来创造软件，现在则是要创造更多 API ，API 从生产资料变成了劳动的产品。

到了这里，我相信大家对 API 以及 API 的未来趋势有深入的了解。

下一期带大家认识现代 API 全生命周期产品，希望有助于大家制定关于 API 的决策。

关于我们

Eoapi 是一款类 Postman 的开源 API 工具，它更轻量，同时可拓展。

项目地址：

https://github.com/eolinker/e...

官网地址：

https://www.eoapi.io/?utm_sou...

如果你对于 Eoapi 有任何疑问或者建议，都可以去 Github 或者来这里找我，等你噢。