API优先的开发方法

无论开发何种类型的应用程序，如果目标是将其融入云服务生态系统，那么研究 API 优先的方法至关重要。

为什么要重视 API？

API 经济正在迅速发展，许多公司将其纳入增长战略。科技巨头如苹果和谷歌正推动以 API 为核心的未来。新兴的互联硬件、可穿戴设备以及即将推出的无人驾驶汽车，充分展示了 API 在现代生活中的重要性。

许多公司最初构建 Web 或移动应用程序，然后作为附加项目开发 API，导致设计时未能充分构建和测试 API。这种方法的问题在于，它会导致人工 API 的设计过程不够严谨。

相比之下，API 优先开发策略强调首先构建 API，再基于该 API 开发应用程序。这迫使团队设计一个对开发人员友好的 API，确保其更真实且易于使用。API 优先开发关注开发人员的利益，从而节省大量工作，并为其他团队提供良好的构建基础。

为了简单起见，可以想象在构建云原生应用程序时，代码提交到存储库后，测试会自动运行，候选版本能在几分钟内上线。在这种理想环境下，多个团队能够顺利合作，提供各自的服务。

然而，如果不进行有效的协调，可能会导致集成失败的噩梦。API 优先方法通过将 API 视为核心开发工件，使团队能够在不干扰内部流程的情况下，专注于彼此的公共合同。

即使不打算将服务整合进更大生态系统，从 API 级别开始开发也会带来显著好处，值得投入时间。

目前的开发过程不是并行的，而是同步的。

一旦需要开发新服务或新功能，研发团队就会开始进行设计。完成后，后端团队开始编写原型（前端和问答等其他团队正在等待）。原型完成后，可以准备 API 文档并与不同团队（问答、前端）共享。

当由于功能、错误、改进或增强而需要更改时，这个循环将再次开始，从而浪费宝贵的开发时间并缩短新服务的上市时间。

code first approach 如上图所示，首先，后端团队开始开发和实现新的 API。其次，将 API 提供给前端团队和测试人员使用和测试。第三，前端团队和测试人员正在构建 sdk、测试等与 API 交互。这就是同步开发。

api-first 开发将允许所有团队并行开发，而无需等待一个团队或另一个团队发布更改。

api first approach 在上图中，我们可以看到创建的第一个 API 是模拟的。其次，后端、前端和测试团队都开始使用模拟的 API。一旦 API 准备就绪，所有团队都可以切换到生产或暂存 API。这节省了大量的开发时间。

Restcase 为 API 提供模拟、调试、自动文档和测试工具，并在所有设计和开发阶段提供团队通知和共享，使协作式 API 优先方法的工作变得更加高效。

如今，移动优先的概念越来越受到关注，指的是从项目一开始就围绕可供移动设备使用的产品进行构建。同样，API 优先意味着构建的是供客户端应用程序和服务使用的 API。

云原生不仅仅是一系列规则或指南，而是一种哲学，某种程度上更是一种生活方式。云原生指南虽然不一定符合云所施加的特定物理要求，但对构建现代应用程序的人员和组织至关重要，这些应用程序需为未来云环境的变化做好准备。

每一个决策和代码行都需围绕 API 满足应用程序的每个功能需求。即使是用户界面，无论是 Web 还是移动，实际上也是 API 的消费者。

通过首先设计 API，可以在编写代码之前促进与利益相关者（内部团队、客户及其他使用 API 的团队）的讨论。这种协作有助于构建用户故事、模拟 API 并生成文档，以进一步明确服务的意图和功能。

这些讨论和测试可用来审查方向和计划，而不需在支持特定 API 的管道上投入过多。

如今，有无数工具和标准支持 API 优先开发，API 规范使用类似 Markdown 的语法（如 API Blueprint 或 Swagger）。这些格式可用于生成文档甚至 REST API 服务器模拟，在测试服务生态系统中非常宝贵。

因此，绝对没有理由认为 API 优先是一条困难或不受支持的道路。这种模式适用于非云软件开发，但特别适合云开发，因为它支持快速原型设计、服务生态系统和自动化部署测试。

这种模式是合同优先开发的延伸，开发人员首先专注于构建应用程序的边缘或接缝。通过 CI 服务器不断测试集成点，团队可以独立处理服务，并保持正常工作的合理保证。

API 优先将组织从瀑布式、精心设计的系统中解放出来，允许产品演变为有机的、自组织的生态系统，能够不断发展以应对新的和不可预见的需求。

构建一个紧密耦合的整体系统会限制适应新需求或支持新消费者的能力。而采用 API 优先的心态，可以将所有应用程序视为支持服务，从而使系统自由增长，适应新的负载和需求，容纳新消费者，而无需重建封闭系统。这种 API 优先的生活方式能够带来显著的投资回报。