未来，API 中的 A 将代表自动化

API 代表application程序编程接口。 多年来，它已经从紧密耦合的命令式规范发展为松散耦合的声明式模型。 当今最常见的 API 是 RESTful，用于实现集成。 无论实现和调用方式如何，API 往往与应用开发相关。 

但另一个 API 经济一直在稳步扩张。 它存在于操作之中。 在该领域，API 中的“A”代表自动化。

运营辖区中的 API 代表的是自动化基础设施和应用服务的入职、配置和运营的能力。 因此，支持操作所需的接口（API）需要注重简化自动化。

当企业全面进入数字化转型的第二阶段并开始在交付和部署流程中扩展自动化时，这一重点非常重要。 要扩大自动化规模，需要能够开发体现应用程序部署流程的一致、可重复和可预测的流程。 

Kentik 的一份关于2019年自动化状况的报告显示，超过一半的组织（53%）已经在使用自动化进行网络配置，另有 40% 的组织使用自动化策略管理。 我们自己的研究表明，这个比例要高得多——86% 的绝大多数人实现了网络自动化。 同一项研究《2020 年application服务状况》也发现整个部署流程的自动化状态越来越一致。

组织所使用的工具也在发生变化。 虽然 Python 仍然是最受欢迎的选项之一，但我们看到 DevOps 和云原生应用对 IT 的影响。 部署管道越来越多地由 Jenkins 和 Ansible 等工具驱动，并由 GitHub 和 GitLab Enterprise 等存储库触发。 展望未来，基础设施和应用服务将由高级分析产生的可操作见解驱动。

在部署管道中调用 API 的是系统，而不是人。 因此，设计操作 API 时必须特别考虑自动化。 这意味着需要考虑几点。

首先，可能有必要考虑可能调用操作 API 的系统。 毫无疑问，Jenkins 或存储库提供的数据与传统网络自动化工具和服务提供的数据有显著不同。 这可能意味着从其他地方获取数据或尽可能默认采用标准化值。 

其次，我们必须解决‘凭证机器’调用 API 的需求，并将其与‘凭证用户’调用区分开来。 我们今天的大多数身份验证系统都假设“用户”是人类。 API 密钥可能是一个不错的选择，但需要在 IT 运营方面进行一些学习，以部署、操作和管理旨在维护仅限机器凭证的系统。 尽管如此，当我们迈向数字化转型的第三阶段和最后阶段时，这一点至关重要，在这个阶段，人工智能辅助应用服务和操作将承担更大的运营负担。

我们可以使用工具来构建脚本，从而实现操作自动化，这真是太棒了。 但重要的是要认识到，在未来，API 中的 A 将几乎完全指自动化——至少在操作的背景下——因为它将影响机器而不是人之间的交互和调用。