最近关于 API-First （API优先）作为设计和开发方法的讨论很多，虽然通向 API-First 的途径有很多，但通常推动 API-First 的一般都是 API 架构师、API 设计师和 API 平台负责人等，很好理解，因为他们对组织中 API 的效率、互操作性和质量最感兴趣。
因此，这些支持者制定了与团队其他成员共享的 API 指南和标准。对于开发人员来说，API 优先似乎是一个崇高目标，但实施该方法时意图和紧迫性经常会减弱。结果导致开发者可能难以遵守这些政策。
管理层关心 API 管理，那其他人为什么也应该关心呢？
1. 开发者喜欢 API-First 的原因
理论上讲，开发者知道 API-First 可以提高他们的生产力，提高代码质量，并改善他们构建的整体用户体验。但当深入了解为什么开发者喜欢 API-First 时，这里有一些原因：
了解 API-First 方法所能实现的结果是迈向 API-First 之旅的第一步。我们看到很多团队完全是因为开发者希望自动生成代码、文档、测试和模拟才回归到实践中去支持 API-First 。
2. 开发者不喜欢 API-First的原因
当你观察那些使用 OpenAPI 等工具设计 API 的团队时，他们常常会对以下几点产生疑虑：
-
耗费更多时间： 在设计过程中需要进行前期工作，并在API合同上达成利益相关者之间的一致意见
-
认知负担： 如果团队没有现有的定义和指南可供参考，从零开始规划用户场景可能会令人不知所措
-
足够好： 目前的流程运行良好，尽管有更好的方法可以采用，但目前还没有改变它的优先级
接下来让我们看看各个团队是如何解决这些疑虑并赢得开发人员支持。
3. 推动组织内 API-First 的方法
对于开发者来说，采用新流程是很自然的，但要充分利用 API-First 带来的好处，最终目标和实现方法得到领导层和实践者的支持，十分重要。根据组织所处 API 之旅的阶段，有不同方法可以提高采用 API 优先设计和开发过程。
-
提高对 API-First 方法能够实现成果的认识
-
建立治理机构或负责人以制定最佳实践和流程，并为开发者提供支持
-
提供最佳实践和指南以简化决策过程
-
创建一个可供参考的内部定义目录
-
提供可重复使用的组件以加快开发速度并保证一致性
-
自动化反馈环节如 API 检查与其他基于政策编码规则
-
通过 API 指标（如开发时间、错误、使用情况和采纳率）衡量进展情况。
-
将激励措施与关键目标相结合，引导期望行为
4. API-First 是一个旅程
采用 API-First 设计在前期规划，以及与利益相关者达成一致方面，都需要时间。但是，一旦设计得到认可，它可以在整个 API 全生命周期中自动生成交付物，从而节省时间。由于减少了返工，在后续开发周期中也节省了时间。
同样，在 API-First 之旅的最开始阶段，需要花费时间和资源来制定指南，并创建可复用的组件。但是一旦流程确定下来，团队将看到开发者生产力、代码质量以及用户体验方面的提升，这进而导致整体上开发人员满意度提高。
Eolink 就是一家 API-first 的优秀案例，通过 DTDD（文档与测试驱动开发 ）和 API First 理论，致力于让 API 管理更简单，为企业用户提供一站式、智能化的 API 全生命周期解决方案，产品能力覆盖 API 规范化治理、API 研发流程优化、API 性能和安全保障、API 数据服务开放及交易等创新服务。
