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