在正常情况下，如果应用涉及多个API并且跨多个微服务，一般可以借助服务编排等框架实现API聚合，实现API的二次封装。但很多情况下应用比较简单，并且也会用到不同的API微服务，这就需要在前端进行API编排。

以下面场景为例，推荐列表的封面是来自专门的资源管理服务器，而方案中仅记录其引用ID，在展示方案列表时，需要根据数据记录中所对应的ID，到资源服务器中去析取。

几个比较重要的实现机制包括：

API分离设计

采用分离的后端API配置，分别完成各自的业务处置，并把API暴露给应用的模块controller。

设置单独Controller的好处是面向业务逻辑层时，有统一的代理作为所有服务的掌控者进行技术实现的总协调者，也就是说，任何业务诉求都可以由controller提供一栈式技术服务。

数据模型设计

VUE是基于MVVM设计理念进行业务逻辑的实现的，因此，采用数据驱动是VUE前端业务实现的关键，在这里我们要考虑这么几个问题：

在页面呈现上，可能会有分成很多层的组件，他们逐级聚合生成对应到一个完整的业务对象，比如一个文章，有标题、正文、分类、封面等，数据如何去和组件中的数据去对应呢？

这里常用的做法是引入一个装配层（Assemble Layer）的概念，引入这个层可以在这个层面基于完整的数据模型去协同各个组件，也就是说组件所代表的VIEW、数据模型、以及Controller要在这个层上见面，并完成统一调度和协调，对于分层组件，在组件设计时就做到v-model的设计，从而使各组件可通过props进行属性下发，通过v-model实现数据采集。

如果一个业务引入多方API的服务，要如何实现聚合？

在拥有统一的Data Model后，因为API后端的天然隔离特性，其聚合需根据Data Model逐级组织数据，如上例获取图片的例子，首先，构建solutions的列表数组，作为前端使用的DataModel，这里因为是比较简单的列表，就直接在这里创建了，复杂的场景下，可以通过预先定义业务对象的方式引入。

然后，在Controller中，我们把不同的API根据要求分级聚合，最终形成了完整的DataModel，作为参数通过回调传导到VUE组件中。

注意这里会有一个坑，就是我们获得数据是异步方法，在上例中，获取方案时solution获得值后再调第二轮的图片时，结果已经返回了并完成了渲染，这时，回调的数据虽然会更新数据，但如果datamodel中没有设置封面图片的属性占位，将会导致图片数据不被更新。所以，这里要切记，一定要为异步调用的数据做属性字段的占位，以使VUE登记数据刷新的跟踪。

虽然比较简单，但在现实实现中经常碰到，因此，做下简单记录，供朋友们参考，大家如果有更好、更高效的方法，可以一起讨论交流。