共计 931 个字符，预计需要花费 3 分钟才能阅读完成。
我常常遇到有做 API 治理然而没有系统管理办法的公司。对于一个齐全在 ticket 模式下工作的 API 团队，更平凡的治理办法有什么益处？
有什么能够改良？
一些心得：对于 API 治理能够察看到的几个点。
对于许多人来说，API 治理的目标只是实现应用程序替换。简言之，咱们做了该做的，因而新技术将最终有一天变成过期的技术，或因为其余起因它不能给我的项目和工作带来任何帮忙，除了束缚和杀死最初期限。
然而多亏了 API 治理，能够带来很多货色。你能够分享你的 API，通过平台进行合作，依据指标受众的需要制订 API 的规范，用标准的格局来调用多个后端。换言之，你能够做很多须要横向性的事，甚至能够是 API 的策略前景。多少次我看到了“面向对象来自 SAP”（”ObjectFromSAP”）API 之类的话？
良好的治理能力施展更好的作用
为了实现 API 治理的战略目标，在我看来，有两个次要的治理办法须要落实到位。
第一方面，相当典型的，我称之为能力核心。领有一个能够从头到尾治理 API 的团队，不论是性能、技术还是开发都要有，能够围绕一个 API 管理工具，延长到整个技术的集成库，甚至是后端的工作。对于很多公司这可能是最失常的配置，然而它不应该成为 ticket 管理模式的申请服务。你必须晓得如何在初期追随我的项目与相干共事（业务线、开发人员、架构师、项目经理）协同工作，最重要的是成为我的项目过程的一部分，认为我的项目带来价值。
另一方面，能够叫调度台。在某种程度上，它是对于治理 api 的，就像治理大型开源我的项目一样。API 团队次要是提供框架和简化流程，然而不是必须的，至多不是什么都要做。它定义并共享其流程，交换最佳实际，集成到公司的 CI/CD 链中，查看开发人员开发的 API 的品质和相关性。这个组织具备特地的可扩大的长处，因为如果包含工具、通信、最佳实际在内的开发人员和流程曾经定义得很好，每个月开发 4 个 API 到开发 40 个 API，就不须要一个 10 倍大的 API 团队了。
总而言之，治理办法和配置是 API 治理我的项目胜利的真正要害。设计 API 非常简单。和很多人一起做很多事件，而且做得好很快，最初会变得很简单。所以，不要犹豫，尝试好的治理办法！
翻译：Eolinker
演示工具：www.eolinker.com