介绍

已完成

新式软件由应用程序编程接口 (API) 提供支持。 反映组织在过去一年中构建的应用程序,很可能大多数功能都是由 API 提供支持的。 从规模角度来看,这意味着许多组织可以有数百、数千甚至数以万计的 API,这些 API 要么是在内部构建,要么与外部 API 集成。 随着对软件的需求不断增加,并且以 API 作为支持该软件的基础层,团队使用的 API 数量预计将会增加,甚至是迅速增加。

场景

Contoso Corporation 是一家虚构的公司,该公司实施了微服务体系结构,采用了 API 优先的方法。 在早期,该组织只有几个团队构建 API,而且这些团队通常也是使用这些 API 的团队。 随着时间的推移,该组织不断壮大,现在有许多团队在制作和使用内部和外部开发的 API。 但是,Contoso 的 API 平台工程师报告说,他们正在接近 API 蔓延状态(组织 API 呈指数级且不受控制地增长的状态),并预见到其他下游问题,包括:

  • API 可发现性和重用性差 - 如果不清楚地了解可用的 API,开发人员最终可能会创建复制现有功能的新 API,从而导致浪费时间和资源。

  • 影子,不受管控的 API - 大多数开发人员可能会在转到其他项目时停止单独管理和维护一些 API。

  • 潜在的安全威胁 - API 平台团队可能无法有效地强制实施组织安全策略,这可能会导致终结点易受攻击且不安全。

  • API 设计不一致 - 有些开发人员制作的 API 可能并不符合组织的统一 API 设计原则,这就需要利用更多的开发资源来重新设计可能要在推出后才能发现不一致的 API。

    显示 API 蔓延的屏幕截图。

此时,API 平台团队开始集思广益,力求推出有效而无缝的解决方案,以防止组织陷入这种状态。 如果你的组织也需要采用策略来将所有 API 集中起来,以便更轻松地进行跟踪和治理,那么本模块正适合你。

学习目标

在本模块中,你将:

  • 了解什么是 Azure API 中心及其提供的优势。
  • 探索 API 中心如何为组织提供集中式 API 清单、治理、发现和使用。
  • 了解如何开始在组织中使用 Azure API 中心。
  • 探索与 Visual Studio Code 等开发人员工具的高级集成。