API First

API First，简言之就是接口先行，但是其背后具体的含义与价值也需要着重探讨一下。

微服务架构下API接口驱动设计与开发

当传统的单体应用被拆分为一个个微服务后，微服务之间的交互、后台与前端的交互基本上都通过接口进行。
但是，传统的开发模式下会暴露出一个老生常谈的问题：很多工作没有办法并行进开展。

比如，前端开发停摆，必须等待后端完成接口开发才能进行下一步的工作；或者前端一边开发一边向后端所要具体需求的相关接口等等。
这些现象都是我们不希望看到的，因为会极大影响整体的开发效能。

针对这一问题，目前最理想的解决方案就是基于API接口驱动的设计与开发。
简单来说，就是API接口需要基于特性与用户需求提前设计、提前规划，同时应当经过相应的评审。

具体落实

对于一个业务功能点而言，都可以拆分为很多内容：

• 后端开发
• 前端开发
• 测试
  • 测试设计
  • 接口测试
  • 界面测试

当所有人都拥有一份共同的API接口契约，那么所有人的工作都可以并行开展，最终的工作也可以集成在一起。

因此，在具体落实上，我们在对用户需求做分解时，就应当将该需求所涉及的接口就详细的确定下来，包括接口的输入、输出、认证策略等内容。这一部分工作通常由产品经理与架构师共同完成：

• 产品经理通过对用户需求的分析来确定服务应当提供哪些接口
• 架构师应当从服务架构、功能实现的维度出发，来对接口做具体的设计。如果接口涉及到对外开放的OpenAPI，则还需要更高层级的API TMG做进一步的接口评审工作。

通过这样对需求的分析与接口的提前设计，能够方便服务发现需求与对应功能点之间的模糊之处，从而将需求细化为清晰明了可实现的接口维度。

同时，这种基于用户需求分析而设计出的接口，本质上是领域服务能力接口，并非是单纯的CRUD、而是各个接口功能的汇总与组合。这样的接口将业务的总体逻辑封装成为单独的粗粒度接口对外呈现，将复杂的处理逻辑留给后端、前端只需要关注独立的用户行为即可。

当我们拥有了接口契约文件（这里一般是一份Yaml接口文档）后，整个开发与测试团队就可以同时运转起来了：

• 对于后端，可以根据接口文档按部就班地完成接口功能开发、单元测试等工作；
• 对于前端，可以不需要等待后端提供具体接口、直接开展相应开发工作，在后端接口尚未完备的情况下，通过Mock的方式来进行前端接口功能的验证；
• 对于测试，可以利用这份接口yaml去生成测试AW、编写自动化测试脚本；

最后，契约的概念也非常重要：微服务之间相互之间的调用接口、后端与前端的调用接口本身就应当确定并规范下来，不允许随意修改、删除接口；同时也不能允许服务想到哪里就将接口加到哪里，这样会造成后期的服务接口治理与监控完全失控。