BLOG | NGINX

打造 API 优先文化和公司（上篇）

Karthik Krishnaswamy

Published January 27, 2022

本文转载自 The New Stack。

floating Japanese torii gate
特写图片来源：Pixabay。

本文是系列博文（共四篇）的第一篇。

过去十年，技术领域发生的最大变革或许是应用编程接口 (API) 的兴起。其原因在于 API 是其他许多重大变革技术的根本推动力：SaaS、云计算、容器编排、分布式应用、无服务器计算，乃至机器学习。

API 让技术的持续模块化成为可能，甚至成为大势所趋。结构化数字服务的编程接口是技术栈的最小组件 —— 这一理念已经深植于软件工程实践中，以至于就许多类型的功能而言，开发人员从未想过要编写自己的库和服务。

鉴于 API 已变得无处不在且必不可少，我们预计未来的大赢家将是 API 优先公司。这些公司将 API 作为其产品的核心或市场推广的亮点。有些企业显然是 API 优先企业，因为 API 本身就是他们的主要产品。

Twilio、Stripe 和 Plaid 便是这种商业设计的三个典型示例。另有一些企业因其文化和理念要求一切均可通过 API 进行消费和处理，也可以归类为 API 优先企业。亚马逊、谷歌和 Facebook 都属于这种情况。

不过，绝大多公司既非科技巨头，亦非 API 即产品创新先锋。现在，各行各业的公司成败与否主要取决于其技术和软件设施。再就是，这些公司应习惯使用 API，并转向 API 优先思维模式和业务实践。

NGINX 经常思考的一个问题是：“企业如何打造 API 优先文化，并转型为一家 API 优先公司？”这是公司在发展其现有技术栈并转向更为云原生、分布式应用架构时所需考虑的核心问题。在这种架构中，API 发挥着越来越重要的作用。

我们正处于 API 经济的第三次浪潮中

在 API 经济的第一次浪潮中，API 大量涌现，一些关键功能也因此被引入应用之中。

Facebook、Twitter 和 Google Maps 就很好地展示了开发人员通过导入 API 源来为应用增加功能的巨大优势。在第二次浪潮中，Twilio 和 Stripe 等 API 即产品公司迅速崛起。这些巨头证明了能够将关键服务作为可嵌入其他应用和服务的 API 销售。

如今，我们正处于第三次浪潮中。在 API 经济的第三次浪潮中，许多内部和外部核心业务流程被分解为 API 前端微服务和小型应用。API 成为了企业利用技术共享信息、简化流程和改进业务逻辑的主要方法。

API 不仅支持更快速、更经济地开拓现有市场，有助于开发新市场，而且还便于内部更好地利用技术。这推动着微服务的发展，促使越来越多的企业从混乱的单体应用模式大规模彻底转向更具可扩展性和敏捷性的“待办工作 (JTBD) ”模式。

JTBD 框架可在企业内部实施更广泛的所有权。每项服务可以有对应的所有者和小团队，从而将“小规模团队”概念确立为企业的主要创建机制，而且还能够确保工作成果的可复用性，有助于构建新产品和功能。

打造 API 优先文化和公司

实际上，打造 API 优先文化和公司需要进行仔细考量并做好准备工作。企业将执行多个步骤，包括确定 API 结构和开发的设计和规则，以及对支持 API 的合适类型的基础设施进行优选和规划。在此过程中，最重要的一点是实现思维转变。API 优先公司需要始终牢记这种思维转变，将 API 作为其主要产品。所有其他产品均源自 API。API 公开的任何内容均可用于下游应用和用例。

API organization diagram

第 1 阶段：设想和评估

第 1 步：为实现理想的 API 优先状态制定指导原则

尽量不要对开发人员发号施令，这样做往往无益。但您可以而且应该制定指导原则，明确理想的最终状态。基本原则可以包括：

API 是每个 JTBD 的第一个用户界面 (UI)。
每个新产品或服务都始于 API 的描述和设计。
API 提供广泛适用的通用服务或实用程序。因此，API 可以完全不受客户端和渠道的限制。
所有 API 都应同样支持内部或外部使用。这是因为我们无法预测哪些 JTBD 将在内部、外部或二者组合环境中执行。
最基本的 API 安全防护要求是身份验证，这点没有任何商量余地。API 既是防火墙上的漏洞，也是横向遍历的便捷路径。因此，在每次会话开始时，必须谨慎地使用 Web 应用防火墙 (WAF) 对其进行保护并执行身份验证。
在发布 API 之前，对其进行定义和记录。切勿本末倒置。

就像十二要素应用定义了应用开发人员针对云环境编写应用的方式一样，您的 API 原则也应定义团队如何根据业务目标编写 API，同时遵守技术原则。

第 2 步：设想目标

先设想一下公司在 API 优先状态下的样子，然后倒推构建。例如，如果您是一家时尚商品销售公司，API 优先可能意味着所有内容、商务和物流渠道均应由 API 架构来驱动，后者为各种消费前端和应用提供信息。

这颠覆了在不同商务平台或经销商内部分别开发移动应用、Web 应用和业务的标准模式。在物流方面，这可能意味着有关运输材料、送至店面批次以及直达消费者运输的所有数据都包含在一组 API 中，甚至是单个 API 中。

以终为始，逆向设计。

第 3 步：清点现有 API 端点

统计企业发布的所有 API，无论是内部使用还是外部使用，数量很可能比您所了解的还要多，因为团队可能会创建 API 供自己使用。这些团队将会是将公司转变为 API 优先公司的最佳变革推动者和布道者。此外，API 清单还可以让您清楚地了解 API 的使用情况、开发人员对 API 使用的考量，以及他们采用的实践和工具。

一般来说，围绕前沿开发人员所用的工具进行标准化 API 开发要简单一些。然后，您就可以鼓励他们推广宣传，或者成为企业内部的“实践专家”。平台团队可利用这些工具集进行管理，同时更好地了解如何将其映射到基础设施和协作工具。

作为一种广泛部署的 Web 服务器和负载均衡器，NGINX 还提供 API 管理解决方案。

第 4 步：确定基础设施和协作要求

在这一步，您需要与 DevOps 和平台运维团队展开密切协作，了解 API 的使用方式以及这些团队的首选工具。

不同的 API 类型和用例可能对环境、计算支持级别及事务附加存储有着不同的要求。

基础设施要求示例：

面向客户的金融交易 API 可能需要低容差 SLA 和极低延迟，这就决定了对此类 API 的支持需要使用分布在全球不同数据中心的 N+3 个实例，从而让 API 处理更靠近客户端调用。在这种情况下，可能需要采用专为高性能而优化的 API 网关。
内部 API 只要求一致性（而非低延迟），可以在较慢的旧有硬件和较少的数据中心内以不太严格的 SLA 正常运行。
由于 GraphQL 被设计用于处理多种查询类型，并经常与图形数据库进行交互，因此与范围更小的 REST API 相比，GraphQL API 可能需要更强的计算能力和更大的通信带宽。

确保 API 创建的协同环境与基础设施支持同等重要。Postman 和 SwaggerHub 是 API 协作和托管平台的领先提供商。其工具能够自动完成大量繁重工作，例如 API 模式生成和文档编制。

为 API 优先设计、创建和实施做好准备

在 API 优先进程的第一阶段进行设想和评估之后，API 优先公司便可通过制定支持性设计原则和基础设施来推动企业文化转型。

本系列文章的下一篇将帮助您从 API 优先进程中获得最大价值，并让至关重要的利益相关者（包括创建者和开发人员）参与打造这种新文化。