可以看出，这个window.api对象实际上是非常复杂的，之所以我们的API源文件这么简单，那是因为apiHelper.js做了大量的事情，从而简化了API的编写。这就是一个架构师该做的事情：将尽可能多的事情交给框架来完成，在保证可扩展性的前提下，让开发人员写尽量少的代码就可以完成工作。
最后，似乎就只差网页中的render()方法了，但是笔者并不打算将其呈现在本文中，因为它真的很简单了并且已经远离了本文的主旨。如果基于上文的信息你还无法完成render()方法的编写，那么你可以使用我们现成的解决方案（加jframe官方QQ群了解吧：651499479）。
最终，我们的API文档服务框架完全实现了我们最初的期望：
（1）API文档编写语法超级简单，可扩展性强；
（2）非常容易编写真实的请求和响应示例；
（3）非常容易编写JSON格式的数据；
（4）发布API文档超级简单：提交SVN即可；
（5）API文档的源文件完全独立于项目源码；
（6）修改API文档将自动创建版本历史记录，在网页中可以非常容易的查看/对比历史版本；
（7）通过WEB浏览器访问；
（8）API数量达到成千上万的时候，能够呈现一个树形目录结构，方便阅读和搜索；
到此为止，我们的API文档服务框架已经介绍完毕。篇幅有点长，那是因为笔者认为API文档框架确实是前后端分离过程中最重要的一个环节，因为相比后端框架或者前端框架，API文档框架不确定性因素更大，基于现有的开源项目很难完成高质量的API文档框架，而不像前端或后端框架搭建过程中成熟的方案很多，完成高质量前端和后端框架相对容易很多。
第四章 我们的前后端分离框架详解
我们的前后端分离框架主要采用了如下技术：
（1）使用VueJs作为前端模板引擎；
（2）使用jQuery以及我们多年积累的JS控件作为DOM操作函数库；
（3）后端采用java体系的spring MVC返回HTML。
接下来笔者将会解释我们为什么会选择这些技术。
1、笔者对VueJs的理解
首先，笔者相信很多人对VueJs或者react到底有什么用都不是很清楚的，因为他们的官方网站讲述了很多的特性，以致让我们分不清楚VueJs的本职工作是什么。笔者在权衡VueJs和react的过程中，也感到非常的困惑。因为按照VueJs官网的介绍，似乎我应该建立以.vue文件为主的项目工程，然后通过编译器将其编译成html、css和js。并且VueJs官网还大量介绍了基于NodeJs的Vue服务端渲染、Vue Ruoter、Vue Loader、规模化，以及打包工具webpack等。看上去这是一套全新的、完整的、包含服务器端的前端开发框架。
我相信Vue官网介绍的确实是一套全新的、完整的前端开发框架。但是，在笔者看来这套框架并不是最好的前端开发框架。对于一个不懂服务器后端架构的前端开发人员来讲，使用NodeJs搭建WEB服务器确实是一个最优的选择，因为NodeJs比java、.NET简单太多了，我相信Vue官网也是基于这个原因才对服务器端解决方案做了大量的介入。
然而我们团队有非常成熟的java服务器后端框架，只需要增加几行代码即可完成Vue官方所介绍的那一堆堆特性。笔者也是把Vue官网上面介绍的这些服务端方案读了很久，才明白Vue官网的真正意图，并且最终明白，Vue官网所描述的架构还没有基于我们的java服务端增加几行代码所得到的架构好。
这是笔者在阅读Vue官网时遇到的最大的一个困惑。后面最终决定：我们只把Vue当做一个HTML模板引擎，这才是Vue的本职工作。
这个决定下的并不容易，因为这会让我们的框架看上去不那么新潮。因为Vue官网上介绍的知识，除了把Vue当做模板引擎的知识外，其他知识我们一点都没有用得上。
Vue官网上还有一个隐形的基础认识没有介绍清楚，因为笔者发现，Vue官网上几乎全部的知识都是基于SPA（单页应用）这个框架下进行描述的，包括webpack、Vue Ruoter等。但是我们的系统是非常庞大又复杂的，根本不可能用SPA架构。关于这一点，笔者也是读了很久才发现，Vue官网的默认设定场景就是SPA架构。
2、为什么我们会选择VueJs？
前后端分离之后，前端工程师需要将通过API获取的数据呈现到页面上，虽然也可以通过jQuery对页面一个一个赋值，但是这种效率太低了，或者也可通过在JavaScript中拼接HTML，但是这种方式太难维护HTML代码了，也很难阅读。因此最好的方式就是使用模板引擎。