[](https://res.cloudinary.com/practicaldev/image/fetch/s--c7UgHjdv--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/uploads/articles/217qqw8ovm3r1fq7nr03.jpg)

API 爆炸式增长

我们正在目睹 API 的巨大爆炸式增长,主要受多种因素驱动,包括:

• 打破单体 - 将大型应用程序与许多服务分开,并将这些相互依赖关系分解为单独的、更易于开发和管理的独立服务

• 更快的创新 - 了解数据需求并提供支持这些需求的 API,促进快速失败和试用概念证明

• 资源共享 - 使组织中跨部门的数据和服务民主化

API 的巨大增长带来了巨大的机遇,但也存在一些挑战。

API 的挑战

随着他们开发和部署的 API 数量的增加,组织面临着许多挑战。让我们来看看其中的一些。

可发现性

开发人员如何找到这些 API?他们如何发现可用的东西?他们在哪里可以找到文档?他们如何订阅 API?最终,开发人员的体验是什么样的?

安全性和性能

您真的希望将身份验证和授权与每个 API 及其业务逻辑紧密结合吗?您将如何管理有关谁可以访问什么的政策?这些政策是基于 API 的,还是组织范围的?如何保护后端应用程序?你如何防止对他们提出过多的要求?如何管理缓存和其他策略,这些策略不仅可以保护您的应用程序,而且可以提高性能。

治理

如何确保围绕 API 设计和创建的流程得到遵循?例如,是否遵循命名约定?是否涉及正确的利益相关者?如何使用现有的服务和功能?

监控和警报

谁在使用您的 API?你怎么知道他们何时何地被访问?他们都被利用了吗?!您的 API 和它们背后的系统是否仍然响应?您如何检查异常或可疑行为?

改变心态

那么我们如何应对和支持 API 的兴起呢?首先,我们需要开始将 API 视为一种产品。从历史上看,注意力将集中在构建应用程序本身,然后解决应用程序如何与其他应用程序一起工作的问题。将这种心态转变为将 API 视为产品,并首先设计 API 会带来许多好处。旅程从考虑谁将使用 API、它将提供对哪些服务的访问等开始。这种将 API 开发置于应用程序其余部分之前的做法称为 API First,我们将在稍后介绍。

支持 API 兴起的另一个要素是通过 API 管理。 API 管理允许我们消除 API 开发的复杂性,因此我们的关注点集中在 API 的构建和支持的业务逻辑上,而让其他事情处理安全性、治理、生命周期管理等。

API 和设计优先

[](https://res.cloudinary.com/practicaldev/image/fetch/s--rITz9W8c--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to -uploads.s3.amazonaws.com/uploads/articles/5lhcvywhm4wxfjol9o0s.png)

API First 介绍了将 API 视为产品的心态。这涉及将 API 视为与应用程序本身同等重要。它们被视为您的项目将要提供的产品和服务的入口,并成为首要考虑因素。无论项目发生什么,最终一切都将使用 API,因此思考从那里开始。如果应用程序采用“自下而上的方法”,则它是最有可能发生变化的组件。 API First 使我们能够从所有关键利益相关者那里获得反馈,并快速迭代设计并获得支持。一旦全面达成一致,其他一切都可以依次跟进。

但是,API first 不是首先设计的。在 API 优先方面,代码优先和设计优先之间存在细微差别。 Code First 首先交付 API,然后是基于使用 API 的所有其他活动。 Design First 寻求就 API 合约达成共识,允许基于 API 的外观进行并行开发。我的同事 Lorie Pisicchio 根据她的精彩博客以及她为API World 2021所做的演讲对此进行了更详细的介绍。一定要检查一下!

API 管理介绍

[](https://res.cloudinary.com/practicaldev/image/fetch/s--BBy74Tqn--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to -uploads.s3.amazonaws.com/uploads/articles/wxy5qkv4g5rbn5xud88c.png)

API 管理是一种管理 API 完整生命周期的方法。除了作为一种方法论之外,还有一些平台和工具可以帮助其应用和治理。

API 管理和 API 网关之间有时可能会混淆。 API 网关代理客户端与 API 及其后端之间的连接。它将对请求和响应流应用任何策略,例如速率限制、节流和转换。作为流程的一部分,API 管理将确定应应用哪些策略,并维护作为 API 生命周期一部分所做更改的历史记录。

一个简单的类比如下 - 想象一下建筑物外部和内部之间的自动旋转门(API),与机械装置(API 网关)一起安装在框架内。门可能以一定的速度旋转(节流策略)以及其他约束,但是决定门的旋转速度,以及旋转门而不是自动滑动门或铰链手动门,如以及如何安装以及使用哪些流程来维护它,是在建筑规划(API 管理)时制定的。可以决定加快或减慢门的速度(API 管理),以及是否完全拆除门并使用不同的类型,包括监督拆除和安装(API 管理)。

因此,让我们研究一下 API Management 在处理 API 方面为我们提供了什么。首先,如果开发人员找不到 API,那么拥有 API 是没有意义的。 API 管理不仅可以帮助我们创建 API,还可以发布 API 并使开发人员可以发现它们,以及提供文档和其他相关信息。我们还可以使用订阅 API 时的信息来培养开发者社区,以及了解他们如何使用这些 API,获得他们的反馈,并最终改善开发者体验。

API 管理还有助于强制使用策略和控制对 API 的访问。因此,我们可以处理客户端是否已被授权或验证使用它。我们可以应用诸如速率限制和节流之类的性能策略,不仅可以防止恶意行为,还可以管理后端系统。

我们可以监控和分析 API 的使用方式、是否被使用,以及检查 API 的运行状况。我们还可以主动寻找异常或可疑行为并采取相应行动,并在适当时触发警报。

最后但同样重要的是,API 管理可以帮助我们进行治理,例如公司范围的政策、命名约定、设计约定等。

总而言之,API 管理使我们摆脱了使 API 可用所涉及的基础设施物流,并允许我们将注意力集中在 API 管理本身所包含的业务逻辑上。现在让我们看一个示例 API 管理平台 Gravitee,它是一个开源产品。

API 管理平台示例概述

[](https://res.cloudinary.com/practicaldev/image/fetch/s--PPtmaTQN--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/uploads/articles/qf9atohwyyq5go6bcmvy.png)

Gravitee是一个完全开源的,低代码,高度可定制的API管理平台,具有高性能的API网关。它是基于 Java 的产品,使用Vert.x 框架。它使用插件的概念来管理策略,包括安全、数据转换、协议中介、监控、身份验证、性能等。有超过 100 个插件可用,如果您碰巧找不到您要找的插件,您可以编写自己的插件。

开发者门户

开发人员门户是开发人员可以探索、研究和订阅您的 API 的地方。他们能够试用 API、阅读文档以及提供评论和反馈。

API 控制台

在这里,API 所有者可以管理 API 的整个生命周期,从设计、部署、策略到应用、API 弃用和禁用。他们还能够监控 API 活动。还有一个 API 可用于 CI/CD 部署和其他自动化。

API网关

网关负责成为客户端和 API 之间的门户。它将应用 API 控制台规定的策略,并且应用的所有规则都将由控制台部署到网关上。

如果您想尝试在本地计算机上启动和运行 Gravitee APIM 平台,这篇博文为您提供分步说明。

结束

希望您现在对 API 管理的功能、API 管理和 API 网关之间的区别有一个很好的了解,以及有机会获得一个可以支持这种做法的 API 管理平台示例。如果您有任何问题关于 Gravitee 或一般的 API 管理,请通过我们的社区论坛与我们联系。