关于未来实现 API 管理系统的几个关键词

[vocalman]

下面将通过几个关键词的形式说明 API 管理的重要性和未来的实现方式。

1.生命周期管理

在整个 API 生命周期中更深入地集成所有工具将进一步提高生命周期循环的速度，而且更重要的是提供满足消费者需求的 API。这与 API 生命周期中的流程改进密切相关，我们看到这种情况越来越多发生在各个产品，因为更多企业开始将 API 视为产品经理指导生命周期的产品。

API 是我们更快地构建软件的核心，使用微服务和驱动 CI / CD 环境与 Kubernetes （ K8s ）进行通信。随着公司采用无服务器架构，通过 API 调用执行越来越多的代码和业务逻辑，这将变得更加重要。各种规模的企业面临的主要问题是：如何以不牺牲性能和成本的方式管理 API 的整个生命周期？否则，企业将只看到他们的成本将随着他们的新数字业务产品的成功而成比例地增加，从而损害长期可持续性。

分布式 API 管理是大规模分布的现代应用程序开发的本质。必须分发 API 管理。允许使用单一窗格集中控制服务，所有报告都显示谁可以访问哪些内容，哪些服务可用，以及这些服务的自动化位置。任何与应用程序本身不一致的事情都会在某些时候与你的集中管理层产生不同步的情况。具有本地化控制和分布式执行，每个服务都会向服务中心报告。当有人试图访问服务时，它可以命中集中认证服务器以确定该人是否应该具有访问权限。

2.应用程序的集成

我们主要关注的是使用 API 来跨应用程序和业务合作伙伴进行集成。企业内部通过使用 SaaS 应用程序替换旧系统来实现 IT 系统的互联网化，这些新应用程序需要与其他企业系统集成，无论是互联网还是传统企业。例如，经常与实现 ERP 系统化的客户合作，那就需要将新 ERP 与其他系统集成。多一个遗留系统可能会导致基于文件的集成混乱。

使用新的 ERP 或者已发布的 API 管理系统是连接所有其他企业系统（如总帐和仓库管理解决方案）的首选集成点。此外，这些系统化的 ERP 解决方案能够通过其 API 提供对企业信息的实时访问。

能够与客户合作，利用向其合作伙伴发布 API，从而提供对此信息的有限访问权限。例如，想要检查库存或检查订单状态的合作伙伴可以使用 API 直接从 ERP 提供其数据视图，这可以通过 API 查询来增强传统的 EDI 流程，以便对从实时响应中受益的某些行为进行查询。

3.微服务

如今每个人都曾经谈论过 API 生命周期，但很多时候你只会为每个开发阶段提供工具，而不是提供一种集成方法，使开发人员能够更轻松地设计，实施，部署并以自动方式管理它。如果设计文档，需要等待数月才能看出 API 是否符合设计要求，那实在是一个很低效的流程。一个开发人员更希望迭代方便并支持敏捷开发过程。我们最终会走上自动化 API 的 DevOps 的道路，即便我们现在还没有到那个时候。

随着未来出现多种形式因素的控制点类型。考虑服务网络和 API 管理将如何叠加是很重要的，API 管理是关于提供服务与该服务的多个消费者之间的关系。规模越大，正式的 API 管理平台就越重要。国内的话可以使用 EOLINKER API Studio 平台 ，国外的话可以考虑 Swagger\Postman 等等。

如果使用 API 而不是共享库来控制单个用户或开发人员团队的 API 访问，则服务网络可以很好地保护两个端点之间的通信。服务网格提供智能网络，以帮助开发人员连接网格中的其他服务。开发人员在学习如何创建在容器、微服务环境和服务网络上工作的分布式应用程序的基础上，将反过来帮助开发人员解决这个问题。

基于微服务架构的应用程序现代化是数字化转型计划的核心。最大的机会在于微服务的 API 管理。对于管理微服务使用的 API，需要具有灵活、可移植且可在任何基础设施（裸机，VM 和容器，公共云和私有云）上运行的“小占地面积”的解决方案。

可以预见的是，在未来的一两年内，服务网络将出现巨大的趋势，更多企业会采用 API 管理并带给每个微服务，以确保应用程序和微服务相互通信的能力。而不是 API 网关也将代理放在边缘以欺骗微服务，用以仅与代理进行通信。

市场已经为 SaaS 解决方案做好了准备，能够将微服务 API 直接给客户提供使用授权和 API 交付选项。举个例子，亚马逊将 AWS 的每个组件构建为可由客户直接寻址的微服务，而且可以编写接收 OAuth 承载令牌的自定义授权者，并根据 IAM 策略将这些授权者转换为访问决策。这实际上很简单，虽然它需要 AWS 客户的大量配置和定制。当市场需求足够大，总有一天我们会看到亚马逊提供的基于标准，资源感知的 API 身份验证和授权产品作为一流的命名产品提供，而不是隐藏在教程中的业务流程。

4.API 其他技术

更多关于 API 管理的工具会在市场上出现，集成度将会越来越高，它代表着这个行业的成熟。使用一系列合适的 API 工具来完成特定的工作并且做得很好，这无疑是最高效率的，也为开发人员提供空间，使他们可以专注于他们的核心项目，并将冗余工作委托给已经完善的服务，以确保质量和效率。

从短期来看，HTTP 很可能会在 API 的形式上产生比目前更广泛的影响。无法实现的用例，现在可以实现传统的通信模式。从长远来看，真正的数据（可能是计算）分散可能会严重改变流程。但是，实现这一概念的工具仍然处于起步阶段。今天最先进的推动者是区块链范式，看到很多公司正在探索区块链如何解决这些问题，也许在未来所有的问题有的新的解决的思路。

虽然与 RESTful API 相比，OpenAPI 规范（ OAS 3.0 ）的采用率仍然很高，但一些公司和技术正在采用超越 SOAP / XML 和基于 WSDL / WADL 的 API。基于 HTTP / JSON 的 RESTful API 等技术的新进展正在被采用，并为行业提供了很好的服务。

此外，非基于 HTTP 的 API 也在不断增加，使得 gRPC，异步 API （消息传递，流媒体，发布和订阅）成为一些公司关注的焦点。例如，构建 AsyncAPI 规范是为了解决基于非 HTTP 的异步 API，如 MQTT，Kafka，WebSockets，AMQP 和 STOMP 协议。这就是 API 管理供应商兴起所在，这是一种将 API 规范从一种格式转换为另一种格式的工具。

API 管理供应商的另一个机会是扩展 API 操作（ APIOps ）中的产品。APIOps 将以与将 DevOps 应用于软件开发生命周期类似的方式应用于 API。例如，GitLab 为 API 生命周期提供完整的 DevOps 工具，从项目规划，源代码存储库到 CI / CD 监控，安全性，问题跟踪功能，可以在同个地方提供给企业。以上所有内容都可以隐藏在 API 管理平台后实现。

考虑到成本未用于正确维护 API 时所产生的成本或安全问题，我们需要更好的方法。GraphQL，SPARQL 和与数据共存的数据安全性提供了一个有吸引力的未来。它不仅简化了，还提供了额外的实用程序，并将数据安全性放在了首要关注的位置。区块链可用于保护数据完整性，允许消费者证明信息的来源。

将来，大部分数据都将实时生成，发送和接收。鉴于每天生成的数据量正在以极高的速度增长，开发人员将很快需要更多的云原生和可扩展的解决方案来管理 API。旧版 API 管理解决方案已经太慢，并不总是能够横向扩展。

5.典型的实践

API 管理工具能提供一套产品来帮助企业大规模管理其 API 设计工作流程。其中一个关键部分是构建在大多数企业中已存在的开发工作流程上，这意味着与 GitHub 等现有工具集成。为此，好的 API 管理工具需要能进行 API 集成，自动将 GitHub 中的信息提取到产品中，并将信息从产品推送到 GitHub。最终结果是为我们的客户提供了更好的体验，并且由于 GitHub 公开的丰富 API 而使其成为可能。API 解决的基本问题是，在最短的时间内以最小的成本解决技术需求。市场上比较好的 API 管理工具有 POSTMAN （英语）、EOLINKER （中英）、Swagger （英语）等。

史基浦机场启动了一个用例，改善了通过机场的乘客体验。有太多的数据是有价值的，它成了一个集成问题，扩展登机牌，跟踪航班，到达离境信息，飞行员警报等信息集成，以实现内部敏捷性，他们决定以 API 为重点，努力实现不同应用程序的集成，打开内部 API 以构建合作伙伴生态系统。

Capital One 是全球最大的银行机构之一，提供各种在线金融服务，包括 API 产品。第三方开发商和合作伙伴可以为其客户提供一流的数字体验，并通过使用 Capital One 的外部 API 打开银行账户，生成个性化信用卡优惠以及跟踪客户奖励来创造新的收入来源。NGINX 技术使 Capital One 能够将其应用程序扩展到每天 120 亿次操作，峰值为每秒 200 万次操作，延迟时间仅为 10-30 毫秒。

还有一个典型的用例是 Netflix，他们需要连接超过 500 个客户端设备，iPhone，Android，X-Box 等。但它们具有良好规范化的 API，可以处理电影中的元数据，处理搜索请求，图像服务，电影的实际流式传输。但是在紧张的网络上受限制的设备，他们为前端（ BFF ）创建了一个中间件后端来使用基础 API，包含客户端需要使用的大部分业务逻辑，然后打开自己的 API 的接口，这些 API 只为该客户端提供服务。当一个新的客户端出现时，他们所要做的就是在客户端代码中创建一个新的 BFF。如果不再需要一个设备的客户端，它们只会关闭该代码并且不会破坏任何内容。

如果是营销人员或是营销技术公司，他们过去常在内部构建软件解决方案。然而，主要问题是获取构建可销售产品所需的数据需要大量的时间和金钱。营销需要大量数据才能有效，但收集和分析所有这些数据的成本非常高，而且因为很明显并非每家公司都能够分配所需的资源来实现软件项目，因此进入市场的技术门槛是不合理的。而现在运用 API 技术可以在几周内构建一个简单的关键字研究工具，大大提高了营销的效率。

参考资料：

https://dzone.com/articles/api-management-additional-considerations

https://dzone.com/articles/api-use-cases-1