声明式接口如何使基础设施民主化

API 是新的 CLI。但当谈到你正在构建什么类型的 API 时，声明式才是主导。

API（应用编程接口）是当今的一项关键功能。 组织在业务层面拥有它们，以促进所谓的“公民开发者”的合作伙伴整合和创新。 应用s拥有它们，以简化集成并将业务逻辑（可能频繁更改）与接口（不应频繁更改）分离。 基础设施也有它们。 从交换机到路由器，从应用服务到中间件和数据库，组成交付和部署管道的基础设施都是通过 API 实现的。

这本身就应该是一个停下来思考的理由，看看这对于新兴的 NetOps 社区意味着什么。 因为虽然组织倾向于对一些关键的应用基础设施组件进行标准化，但他们不太可能仅对一些关键的网络和应用服务基础设施组件进行标准化。

组织平均使用十六种不同的应用服务来使其应用运行得更快、更安全，而这些服务肯定是由多个基础设施组件提供的。 如果我们慷慨地假设每个组件有三个应用服务，那仍然有五种不同的设备 - 具有五种不同的 API。

问题在于，基础设施提供商通常对“API 是新的 CLI”这一说法的理解有些过于字面化。 也就是说，API 仅仅是 CLI 支持 REST 的反映。

任何使用过跨基础设施组件的 CLI 的人都知道，CLI 导航与基础设施的对象模型非常紧密地映射。 API 通常无法做到更多，只能将此设计转移到 HTTP。 这意味着那些试图利用 API 的人也必须了解相关设备的对象模型。

这种抽象层次阻碍了自动化和编排的向前发展，因为我们现在不仅需要找到自动化人才，还需要找到在五种或更多不同网络基础设施模型方面具有一定专业知识的自动化人才。 所需的专业水平通常也需要领域知识，从对 VLAN 配置和路由的基本了解到虚拟服务器、虚拟 IP 地址、节点、成员和池之间的关系。

暴露基础设施的底层复杂性不利于鼓励采用和实现自动化。 接口的目的应该是抽象模型和逻辑，以保护用户和操作员免受其复杂性的影响。 GUI 实现了这一点，因为无需浏览对象层次结构即可配置简单服务。

这就是为什么当我们发现 API 再次引入这种导航噩梦时会令人沮丧。

这一问题并不只存在于网络和应用基础设施。  也就是说，MuleSoft 在其“ API 价值上升”研究中发现，客户和合作伙伴对 API 集成的最高需求（47% 的受访者）是“适合特定业务需求的定制 API”。 随之而来的是更好的文档（19%）、“无代码”集成模板（19%）以及他们需要和使用的 API 的 SDK 包装器（13%）。

所有这些都可以归结为对简化的请求。 在技术领域，简化意味着抽象。

这就引出了这篇文章的重点，即声明式接口就是这种抽象。 通过简化当今用于配置、管理和集成基础设施的接口，声明式接口使基础设施民主化并开辟了机遇。 

声明式与命令式

一般来说，声明式和命令式都可以被视为 API 的类型。 当有人说 API 时，你首先想到的是命令式 API。它告诉目标系统如何做某事。 如果您要添加虚拟服务器，那么您将准确地告诉它如何执行此操作 - 即使需要五个或十个或更多单独的 API 调用。

这意味着告诉它创建一个具有适当属性的特定对象，比如具有 IP 地址的节点。 然后您必须单独告诉系统创建要分配到的池，并为其命名。 那你必须......好吧，现在你明白我的意思了。 命令式 API 要求用户不仅要了解系统及其对象模型，还要了解实现预期结果所需的步骤。

这就是您必须支付的 API 税。

现在，命令式 API 总体来说并不是一件坏事。 当您构建 GUI 或与其他需要命令式 API 所具有的粒度的系统集成时，它们非常重要。我们也需要命令式 API，但不适用于面向自动化和集成的 NetOps 和 DevOps。

但对于我们其他人来说，我们不需要知道那么详细程度。 事实上，要求有如此深厚的知识可能会令人不快，并会减慢自动化和编排工作的速度。 它当然不利于基础设施民主化，也不利于为 DevOps 和开发人员提供自助服务模式，更不用说特定基础设施领域之外的 NetOps 了。

这就是声明性 API 发挥作用的地方。

声明式接口指定您想要做的事情，并将逻辑和工作流程留给系统来解决。 因此，您不需要具体告诉系统创建一个节点和一个池并对所需的对象执行所有正确的逻辑，而是描述它们及其关系。

一些声明性接口使用 JSON，其他使用 XML，有些甚至仍然使用简单的表单数据。 他们共同的观点是，他们假设数据以简单、直接的方式描述对象，而这种方式几乎不需要理解对象模型和系统层次结构。

例如，这个声明是相当易于人类阅读的。 它假设对对象模型有基本的了解，但并不要求对特定产品有认证才能写出声明： 

“web_pool”：{
“类”： “池”,
“监视器”: [
“http”
],
“成员”: [
{
“服务端口”: 80,
“服务器地址”: [
“192.0.1.10”,
“192.0.1.11”
]
}
]
}

这就是声明式接口的价值显现出来的地方：减少领域知识以及配置和配置基础设施的复杂性。 通过降低所需的专业知识水平，NetOps 不仅可以更快、更高效地工作，还可以鼓励 DevOps 和开发人员利用该功能。

采用声明式接口作为管理基础设施的标准方法可以立即拓宽人才库，从而提供自助服务和高级自动化功能。 上述声明式接口几乎不需要任何解释，DevOps 和开发人员就能理解和使用。 另一方面，命令式接口需要投入更多精力来学习基础设施特定的模型和工作流程，然后才能预期结果。

声明式接口通过简化自动化部署管道和将系统与其他基础设施服务集成所需的配置、配置和管理，使基础设施民主化。 基础设施民主化意味着更快、更智能的自动化，以及鼓励跨运营领域协作与合作的能力，这些对于从 NetOps 和 DevOps 运动中获益是必要的。