最近关于 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(文档与测试驱动开发)
文档驱动开发:项目开发前,先把文档写好,明确功能需求、入参出参定义、异常情况处理等,再进行开发。
测试驱动开发:项目开发前,先写好测试方案/用例,要求代码顺利通过测试,如不通过则持续进行改进。