企业平台API治理的力量

如今，当你听到关于API治理的讨论时，大多数讨论都集中在我们认为的API设计治理上，即我们“治理”API的表面积的一致性。这是治理的一个显而易见的起点，因为API设计的不一致性可能会导致下游出现最明显和痛苦的问题。

然而，虽然你需要开始掌握你的企业API设计治理策略，但我们认为，你需要在更广泛的范围内投资于我们所说的“平台API治理”。这意味着不仅要投资于每个单独API的发现、可靠性、一致性、交付和可观察性，还要投资于它们周围的运营。

大多数投资于API治理的客户要么刚刚开始并希望了解他们应该做些什么来塑造治理，要么已经开始投资于API设计治理，并面临在所有团队和API中一致地应用治理的挑战。

如果不能发现团队、API以及跨运营工作的情况，他们就无法有效地在大规模上应用API设计治理。此外，如果不能在大规模上观察和评估整体质量和治理的结果，他们就无法将治理应用到更多的团队上，而只能停留在少数几个团队上。

我们发现，那些在“以API为中心”的旅程中走得更远的组织，正从更广泛的平台角度看待治理，确保API是可发现的、可靠的、设计一致的，并通过明确定义的生命周期进行交付，同时确保沿途的一切都是默认可观察的。

API定义

我们观察到企业组织在API治理方面遇到困难的一个原因是，不仅API本身缺乏发现性，围绕每个API的工件、文档以及其他所有工作也缺乏发现性。你无法治理你找不到的东西，而API及其背后的操作越可见，API治理就越有可能深入人心。

平台API治理的基础是确保发现是您的操作中的默认设置：

工作区：确保每个API都有一个私有、合作伙伴或公共工作区来访问每个API周围的操作。

OpenAPI：确保始终有一个人类和机器可读的API工件可用作每个API的真实来源。

Repository：为每个API建立一个Get储存库，将OpenAPI和集合同步到存储库中，作为生命周期的一部分。

环境：提供开发、试运行生产和其他可手动或自动应用的环境。

文档：要求所有API都有完整和最新的文档来证明什么是可能的。

团队：将每个API背后的团队作为列表提供，提供名称和联系信息供消费者使用。

这是您API治理的基础。每个API都应该具备这些元素，并且当团队建立新API或使现有API达到当前标准时，应该有一个蓝图可供遵循。在这些领域的投资将使API设计和其他API操作方面的治理成为可能。一旦您掌握了这些领域，并意识到每个领域都有自己的API，您就会看到完全新的方法来提升您团队中的API治理工作。

API实例

我们接下来希望将API治理的范围扩展到每个API实例的整体可靠性上。我们希望在所有API上提供一套基准测试。这确保了每个API的业务目的得以实现，同时也确保了它以符合服务水平协议（SLA）的方式执行，并且不会在操作中引入任何漏洞或安全问题。

建立团队能够自信地提供和操作我们应用程序和集成背后可靠API的通用方式至关重要：

Contract Testing Collection：生成一个集合，为每个API操作提取JSON模式并验证请求和响应。

性能测试集合：生成测试一个或多个API操作的单个集合，确保它满足最小时间阈值。

安全测试集合：生成应用一组通用安全漏洞测试和第三方API安全服务的单个集合。

从历史上看，API治理的这一维度属于质量、测试和其他运营领域，但将其作为API治理堆栈的一部分来考虑是非常有意义的。

这将可靠性作为治理的一部分，并允许我们使用相同的工件和工具来进行测试，以治理我们的API以及围绕它们的API操作。我们可以测试API的实例、这些API的表面积，以及推动这些API在众所周知的API生命周期中前进的操作和基础设施。

API设计

现在我们来到了人们通常在谈到API治理时会提到的平台治理的一部分——即管理你的API设计。API设计治理是确保你的API表面积的技术细节尽可能一致，无论哪个团队设计并开发了该API。这是我们认为很重要的一个API治理领域。

然而，如果没有在已知工作区中的单一信息源（OpenAPI），这个领域也会变得更加困难。当你想到你可以用各种方式来清理你的API的OpenAPI时，这很快就会变成一个陷阱——所以我们建议从小处着手。

设计治理集合

信息：确保有标题、描述和其他基本信息属性。

版本控制：要求对每个API应用标准的语义或基于日期的版本控制。

操作：确保每个操作都有摘要、描述和ID。

参数：规范参数名称的格式，并且都有说明。

响应：推送一组常见的状态代码、媒体类型和模式响应。

模式：使用JSON Schema组件标准化所有请求和响应模式。

在这一层面可以应用许多其他的治理规则，但这里提供了一组应作为API治理工作早期解决的入门关注点。团队将通过确保这些简单规则在API操作中一致应用而学到很多，从而使所有团队都能使用集合运行器手动应用治理，使用监视器进行调度，或将其集成到CI/CD管道中。

我们能够使用与测试每个API实例相同的基础设施来测试API的表面积，以确保任何团队的设计都保持一致。

API操作

API治理不是一劳永逸的事情，而是需要持续进行，并与您现有的软件开发生命周期相结合，进行实时监控。运营治理使我们能够自动化治理中的可靠性和一致性部分，我们可以配置、优化和自动化我们的网关、门户、文档以及API操作的其他构建块。

然后，我们利用与测试单个API相同的基础设施来“测试”我们API的表面积以及围绕它们的操作。

监视器：确保你在监控运营，即使团队在做其他事情时也要注意。

合同：每24小时安排一名监测员对合同进行测试。

性能：每小时有一个监控器测试API的性能。

安全性：每24小时有一个监视器来测试API的安全性。

治理：每24小时有一个监视器来测试API的治理。

管道：确保您在CI/CD管道层应用治理，在每个构建中运行契约、安全和治理测试。

合约：在管道中运行合约测试集合。

安全性：在管道中运行合约安全性收集。

治理：在管道中运行治理测试集合。

网关:通过网关管理API的部署，允许手动和自动配置以及可观察性。

身份验证：确保网关身份验证已正确配置。

使用计划：要求每个API在特定的使用计划中运行。

使用历史记录：检查API的使用日志以了解常见模式。

对操作的治理不仅仅局限于监控我们的测试、安全性和设计治理。将其融入我们的CI/CD管道，可以将其扩展到其他操作领域。

用于测试每个API实例和治理API设计的基于集合的方法同样可以用于验证文档是否完整且已更新，是否包含示例，以及是否始终自动生成SDK和代码片段。当你意识到你的API操作本身也有API时，你对API治理的方法就变得比仅仅设计你的API要广泛得多。你的团队可以变得更加高效，实现更高水平的质量，同时实现大规模的治理。