众所周知，API是一种接口。您可以使用此类接口将业务功能和业务数据作为有价值的信息传递给客户。例如：一家零售店可以通过API将其商品出售给足不出户的客户。显然，如果您想发展自己的业务，则需要接触更多的客户。API恰好就能够满足这一点。借助API，您可以与客户、合作伙伴、甚至其他员工进行虚拟的连接，进而构建出完整的供应链。

可见，API的基本思想是：构建一个向内部和外部用户公开的业务功能接口。而通过互联网(或内网)公开服务的最常见、且广泛被采用的机制(或协议)，便是REST over HTTP。您可以将接口定义为客户与系统之间的协约。此类协约可以通过采用Swagger、Open API Specification(OAS)或RAML等标准。一旦使用了标准机制来定义接口(协约)，用户就可以据此来准备其客户端应用(包括移动和Web应用)，而不必考虑协约背后、以及业务应用内部发生的事情。

那么，承载所有这些接口，以便客户可以访问的接口组件，就被称为API网关。下面，让我们来看看API网关是如何通过API，向用户交付业务功能的。

图：使用API网关向用户公开业务功能

如上图所示，用户可以通过联系API网关，来获取客户端应用所需的业务功能。您可以将网关想象为一个门卫或接待员，它通常需要具有以下功能：

• 基于标准格式(例如REST、Swagger、OAS)的托管类API。
• 允许多个用户同时访问。
• 使用某种形式的身份验证，来验证API用户。

当然，随着API程序的普及，您可能还会用到或提供许多其他高级的功能。

如何使您的API受欢迎?

现在，让我们来看两个通过使用API网关，向内、外部用户开放特定的功能和数据，以改善业务流程的典型示例。

• 一家保险机构向保险经纪人公开了一组API，以注册新的交易，并为客户生成报价。据此，经纪人和组织节省了大量的时间和精力。
• 某个制造型组织向代理商公开了一组API，以检查生产线中某些产品的可用性，并根据该可用性做出订单和取货的决策，进而协助经销商计划其销售、订单和运输的安排。

目前，我们有着多种接触新客户的方式。其中较为简单的一种方法是：开发并发布移动应用到诸如Google Play商店或Apple应用商店中。当然，我们需要配合进行一系列的营销工作，促进应用能够实现流行下载。

不过有了API，我们就可以通过对外发布，与供人调用的方式来创造价值。为此，我们需要通过某个API商店或开发者门户，来让自己的API被发现，并与整个架构进行交互。

图：通过开发者门户扩展您的API使用

如上图所示，开发者门户允许外部开发人员使用您的API，并构建出与其当前应用相集成的更好体验。例如：汽车销售公司可以使用保险公司的API，让汽车购买者直接从其汽车购买的应用中获取对应的保险。可见，开发者门户可以提供如下基本功能：

• 提供API目录，以供用户轻松地搜索和浏览到。
• 通过相关的文档，来全面介绍API及其用法。
• 提供测试API各项功能的机制(可选)。

为了提高在与外部开发人员交互时的整体效率，一些API管理产品还会包括如下高级功能：

• 给每个提供API评分和评论功能。
• 能够通过社交媒体来共享API。
• API的使用情况分析。
• 细粒度的API安全配置。
• API的营利状况。

您可以按需选择具有上述功能的API管理平台。

如何在组织内部扩展您的API策略?

让我们来考虑这样的情况：组织内部的会计部门准备“入住”现有的API平台。他们不仅希望成为API的使用者，也希望托管自己的API，以供内部其他部门使用。那么，满足该要求的最简单方法是：从会计部门获取API的具体要求，着手开发，然后在管理API平台的团队的监督下将其发布出去。不过，此类方法在流程上容易造成各种瓶颈，时下流行的敏捷开发实践和交付实践不太适合。在此，我们就需要引入API Federation的概念了。它的基本思想是：我们应该能够根据不同部门的需求，来联合管理API平台，而不是由一个单独的团队说的算。据此，该平台应能够能够为各个部门提供必需的独立性和敏捷性，并能够开发和维护自己的一套API和安全策略。

当然，这并不一定意味着您应该为每个部门分别部署一套API平台。相反，您可以使用“多租户”的概念，在多个部门之间共享相同的API平台。此举的好处包括：更大的灵活性，更低的成本，以及更容易被采用的API平台。

图：通过Federation扩展组织内的API平台

如上图所示，一组方便内部业务部门使用的新API被部署到了API网关处。它们是由各个业务部门的开发人员所开发的，因此只有该部门的用户，才能在开发者门户中查看这些API，并在网关中执行它们。

当然，我们需要在网关级别上具有特定的、基于角色、或基于组的访问控制功能，并且在开发者门户级别上，需要有与之相对应的可视性控制。目前，大多数API管理供应商都能够通过“多租户”功能，来支持此类需求。

如何使您的API平台成为云原生?

为了能够让API平台设计面向未来，我们往往需要其具有云原生(cloud-native)特性。也就是说，我们的API平台需要具有云服务的四大优点：高可用性、弹性伸缩、节省成本、以及即付即用。

其中，可伸缩性和可维护性主要得益于模块化的体系结构。如果您将所有的功能都整合到某个单一的应用中，那么可扩展性会变得相当困难。在此，我们可以借助微服务架构之类的概念来实现。也就是说，在将功能组件分为彼此兼容、但又独立的模块之后，我们的部署将变得更加灵活。下面，让我们来看看如何为API平台定义云原生的架构。

图：具有微型网关的模块化API平台

在前文中我们讨论了：将API网关、以及API开发者门户分别视为一种单独的组件。那么在上面这张图中，我们将API网关的安全性部分也单独地视为一个的组件，并称之为API密钥管理，以便它能够独立地处理那些与安全性相关的需求。

在此，我们还引入了两个分别用于API分析和API开发的附加模块。如果您想根据不同的参数，分析API的使用情况，并据此做出决断的话，那么API分析组件最合适此类需求。而API开发组件是API开发人员在构建API时需要交互的组件。它既可以基于GUI的接口，又可以与源代码管理系统、以及Jenkins之类的构建管道，绑定到完全自动化的过程中。

上图中的另一个关键点是：内、外部网关的分离。它保证了不同API在执行或运行时(runtime)不会互相影响。此外，图中灰色六边形的组件描述了可以在某些用例中被使用的微型网关。您需要在隔离的运行时中部署一个、或一组可以独立于其他组件运行的指定API。

最后，图中所有带有docker图标的组件，都能够像docker那边被部署到云原生的平台中。您可以根据自己企业和项目的实际情况，选取如下基础架构类型：

• 本地(物理/VM)
• IaaS(基于VM)
• 容器式
• Kubernetes

平台的选择

有了前文关于API平台的基本介绍，您一定想知道有哪些可供选择的API管理平台。下面便是我为您罗列五种的常见供应商：

• IBM API Connect(https://www.ibm.com/cloud/api-connect)
• Apigee(https://cloud.google.com/apigee)
• WSO2 API Manager(https://wso2.com/api-management/)
• Kong Enterprise(https://konghq.com/products/kong-enterprise/)
• Mulesoft anypoint platform(https://www.mulesoft.com/platform/enterprise-integration)

原标题：How to Select an API Management Platform for Your Business