本世纪初，Amazon、eBay 和 Salesforce 等公司推动了网络应用程序接口标准化的趋势。由于开放式网络 API 的网络不断扩大，任何人都可以使用这些 API，因此应用程序的开发和集成方式发生了彻底变革。
在此期间，Amazon 创始人 Jeff Bezos 给员工们写了一份备忘录，这就是著名的 “Bezos API Mandate”。据次级资料显示，这份备忘录包括两项战略要求，任何 IT 领导者在寻求开发团队工作价值最大化时都应考虑这两项要求。第一，任何团队开发的软件之间的所有接口都应通过 API 来实现；第二，团队在编写内部 API 时，应将其视为供公司外部人员使用。
这种方法在很大程度上解释了 Amazon 是如何将其计算基础设施外部化的：首先是 Merchant.com（该公司的电子商务即服务平台，供零售商建立自己的在线商店），然后是Amazon网络服务（Amazon Web Services），这是一种更广泛的服务，此后就可以独立运行了。
时间快进到 2023 年，IT 领导者在过去二十年中总结出了更多关于有效开发和使用 API 的经验。macH 联盟是一个由近百家技术供应商组成的全球联盟，旨在促进 “开放和实现最佳的企业技术生态系统”，重点关注微服务和 API。
在此，MACH 联盟成员和其他 IT 领导者提出了以下三条戒律，这些戒律应成为任何 API 战略的基础。这些原则不仅能确保软件系统良好地协同工作，还能确保团队协同工作，为企业的整体软件开发战略服务。毕竟，就像应用程序接口一样，当一个团队为其他团队提供服务时，承诺必须明确，边界必须得到尊重。
将 API 战略发挥到极致的最有效方法就是采用所谓的“API 优先”方法，即从一开始就将 API 作为软件开发战略的构建模块予以优先考虑。
API 优先型组织更注重接口而非集成。在编写任何其他代码之前，他们首先定义 API，包括其执行的服务、接受的输入和产生的输出。这样，他们就不会集成各种软件组件来构建单体应用程序，而是使用组件化的服务，通过应用程序接口提供给生态系统。Valtech 公司全球技术高级副总裁、MACH 联盟总裁 Casper Rasmussen 说：“不采用 API 优先方法的组织在设计 API 之前先开发软件，这限制了 API 的实用性。”
Rasmussen 说：“API 优先是指设计通用的接口，而不是针对特定的用例。如果你在现有的传统软件上安装了 API，那么你就不是 API 优先，至少在历史上不是。传统软件带有关于它做什么、对谁做以及在什么用例中做的假设。应用程序接口优先的通用性要强得多。举例来说，假设消费者是网络客户端的 API 策略。它使用 html 进行通信，因此很难在其他环境中使用。”
API 优先的方法使企业能够充分利用微服务架构，这是 SOA 的一种变体，在这种架构中，应用程序的结构是松散耦合服务的集合。The Lego Group 就是一家采用 API 优先方法的公司，因为这一概念模仿了 Legos 产品系列，积木上的标准接口使用户能够拼凑出一个更大的整体。
Lego Group 市场营销和渠道技术副总裁 Niall Edwards 说：“我们的战略重点是构建松散耦合的系统，并由我们的产品团队提供支持，他们构建并运行 API 来公开他们的服务。多年来，我们的 Lego.com 技术平台一直完全基于微服务和 API，现在我们正在所有技术领域推广这种方法。现在，我们正在将这种方法推广到更加单一的企业系统中。”
Lego Group 提供了一个完美的例子，说明 API 优先的方法如何偏爱微服务，而不是更大、更复杂的功能。新的 API 应能提供狭义的服务，可供各种应用程序使用。旧系统可以通过 API 进行改造，使应用程序能够像使用新开发的服务一样使用传统服务。
随着传统技术投资的更新换代，CIO 们最好确保只有在新供应商提供微服务并符合 API 优先原则的情况下，才能将其引入。
为确保内部和外部不同团队开发的软件组件之间的松耦合和高度一致性，有必要制定共同的 API 政策。
该政策应说明某些服务由 IT 部门集中执行，即使大多数 API 工作是由不同的开发团队独立完成的。例如，为确保一致性，应集中管理访问控制，所有应用程序接口都应使用一种识别和验证方案。数据格式也应集中管理，以确保统一性。最后，服务水平协议（SLA）应由 IT 部门定义和控制。例如，你可以规定，对于任何面向客户的服务，应用程序接口都应在 50 毫秒内做出响应。
Edwards 说：“如果不明确谁负责什么，那么就会出现混乱，没有人知道真相的来源。企业数据模型必须明确指出谁对哪些数据负责。数据的用户需要知道，他们可以缓存和使用这些数据，但绝不能更改它们。对数据的更改只能发生在源头，而且这些更改应该是可发现的，并向所有消费者公开。”
API 需要得到微服务的支持才能发挥最大功效。CIO 应以此为前提定义 API，然后在内部构建服务，或选择提供符合这种方法的服务的供应商。
身为 Commercetools 公司首席战略官、四本关于 API 和微服务的书籍的作者 Kelly Goetsch 说：“API 应该是可独立调用的、无状态的、可怠用的。这意味着应用程序可以使用一个应用程序接口，而无需先调用另一个，并且服务的内部值不会发生变化，不会导致每次调用都产生不同的结果。例如，您可以多次调用应用程序接口来添加到购物车，如果它是等幂的，那么每次调用时都会以相同的方式运行。”
Rasmussen 说：“最后，该策略应确保不区分内部 API 和外部 API。Bezos API Mandate 的精妙之处在于，API 默认需要外部化。如果你看看 AWS，它最初只是一个内部项目，他们只是改变了公司内部已经在使用的 API 的访问权限，就将其提供给了外部世界。”
一旦制定了 API 政策，关键是要确保所有团队都能遵守。面对如此之多的移动部件、连接和传输中的数据，这是任何 IT 领导者都不应忽视的一个重要方面。
要实现 API 愿景，可能需要提供如此广泛的服务，因此还必须对贵组织正在创建的 API 以及贵组织可能依赖第三方提供的 API 进行索引。
Goetsch 说：“CIO 应制定 API 目录和管理该目录的策略。目录应定义 API，并包含企业需要的所有功能。然后，你就可以决定是构建还是购买提供这些服务的软件。”
Goetsch 指出，虽然目录应集中维护，但实施的责任应留给各个团队或外部供应商。但开发服务的人员必须遵守目录中的规定。
他说：“实施应用程序接口的团队可以选择他们的数据库和其他很多东西。但如果他们搞砸了，就要追究他们的责任。你可以非常快速、轻松地判断一个团队的管理是否正确。如果应用程序接口出现问题，你就知道出了问题。”
中央目录应该有完善的文档记录，并配有发现工具，使内部和外部用户能够根据需求描述或一组关键字找到应用程序接口。Edwards 认为：“Lego Group 在集中式可发现性工具方面进行了投资，以帮助开发人员找到彼此的 API，并利用它们组成更大的产品，就像人们使用乐高积木一样。”
通过遵守这三条戒律并借鉴多年的经验，IT 领导者可以建立一个框架，确保每项服务都有清晰的路径。消费者可以信赖一个可靠的界面，而生产者则可以获得构建服务所需的自由。每一方都可以在自己的时间内进行创新。
来源：www.cio.com
