在我之前谈API网关的时候曾经谈到过快速开发平台，即将API快速开发的一些内容放入到API网关中，实际来看围绕API全生命周期管理，本身包括了开发态，运行态，运维态。
对于API网关更多的是解决运行态的问题，API网关本身应该轻量化设计，不做太多的协议转换，适配，数据映射等工作，这些工作应该放到API开发平台来完成。API开发平台最终就是开发完成并暴露一个标准的Http API接口，并将接口注册和接入到API网关。
API全生命周期管理
围绕API全生命周期管理来看，整个子系统划分如下：
简单来讲这部分可以分解为四个子系统，即API开发平台，API网关引擎，API监控运维平台，API全生命周期管控平台。
对于传统ESB总线里面的适配器，协议转换等相关比较重的内容，都可以转移到API快速开发平台来完成，即API开发平台暴露标准的API服务接口，注册和接入到API网关引擎。而对于API监控平台则从引擎采集日志信息，进行API性能监控和日志监控分析。
API全生命周期管控平台实现API接口从设计，开发，测试，部署上线的全生命周期管理，也可以理解为底层三个子系统的一个统一管理门户，实现和下面三个子系统集成。
对于API开发平台开发和配置完成的微服务API接口，可以支持自动部署到微服务运行平台。
基于对象建模驱动
在整个API开发平台实现中，核心思想仍然应该是基于对象建模驱动，通过对象建模很好的实现接口和底层数据库，数据库表之间的解耦，也方便实现底层多数据库，多表的支持能力。
当前很多API快速开发平台都是基于数据库对象或表，直接发布类似CRUD的API接口服务，但是基于是数据库表的直接发布，我们仍然建议逆向对象这层，方便后续在对象层进行相关的组合，规则扩展等操作。
对象建模和API接口契约
可以直接在API开发平台创建对象，并对数据项进行定义，对象是一个多层的树状结构实体。一个对象可以向数据库生成多张表。对于已经存在的数据对象，也可以进行组合，将多个组合为一个复合对象结构。
对象的好处即是一个完整的对象属于同一生命周期，可以一起进行事务控制。
一个设计好的对象可以默认生成标准的POST，GET，DELETE等接口操作方法，类似下图，整个对象接口契约的生成也应该是自动的。
定义好的对象可以直接生成类似RAML，YAML，WADL等接口契约文件。
类似Swagger工具一样，完成的对象建模本身也可以直接导出不同语言，不同开发框架下的客户端消费框架，服务端提供框架代码。
对象适配到数据库
前面讲到了，既可以是数据库直接逆向对象，也可以是在对象建模完成后，将对象适配到数据库。完成对象和数据库表之间的映射。一个对象可以映射到多张数据库表，因此在映射过程中除了完成数据库表和字段映射外，还需要完成主外键关联关系的映射操作。
在完成对象模型和数据库表之间的映射和适配后，基本发布的API接口已经可用。
API接口发布
对于完成的对象定义，可以选择具体发布哪些API接口服务能力。比如可以只选择发布查询接口，也可以只选择发布数据导入的POST接口等。
注意API接口的发布，具体可以基于全局的对象建模，配置具体需要发布到接口的数据项信息。很多时候我们对数据对象的操作，并不是操作整个对象全集，而仅仅是部分数据项。
API接口模拟测试和验证
可以对发布的API接口进行模拟测试和验证，因此需要提供在线的API测试工具，能够方便在线进行API接口的测试工作。同时可以对测试过的用例和测试数据进行保存。
API接口文档生成
支持自动生成API接口文档的能力。这个地方可以直接对接类似开源Swagger等工具来实现API接口文档的自动生成功能。
对象常用接口操作
当对象定义完成后，可以基于对象进行相关API接口的自动生成。在这里简单列下基于对象常用的接口方法，主要包括新增一条数据，基于主键更新，查询，删除数据。其它的则是基于条件查询对数据进行查询相关操作等。
在GtiHub里面开源又一个xmysql的工具，可以直接将整个MySQL数据库中的数据库表发布为RestAPI接口，具体可以安装试用。
npm install -g xmysql xmysql -h localhost -u mysqlUsername -p mysqlPassword -d databaseName http://localhost:3000
注意需要提前安装Node.js，部分接口方法列表如下：
由于生成的API接口都没有相关的权限控制，因此该开源工具也仅仅用于自己测试和验证使用。但是生成的方法和API可以作为API开发工具时候参考。
实际上对于API接口的生成，我们并不建议对于复杂查询条件下的查询都通过GET方法来实现，更好的思路还是通过POST方法，将查询条件作为POST输入进行处理。
复合对象一次生成
比如将订单作为一个对象，实际包括了订单头和订单明细表，而在进行API生成时候可以一次生成基于订单对象的插入操作，查询操作。最终查询出来的是一个订单复合实体Json数据。而对于订单插入，也是先准备好整个订单实体信息，一次调用API接口完成数据插入，也方便在API接口实现的时候进行事务控制。
复合对象生成的API接口更类似于领域对象暴露的API接口服务能力。
分页支持
对于查询API接口服务的生成，应该支持分页能力，具体分页的大小，本次查询访问具体页数等信息都可以作为API接口的查询输入参数进行设置。
直接定义API接口并发布
在前面谈到了基于对象来发布API接口服务，但是还有一些业务规则逻辑类接口，复杂的管理数据查询类接口等并不能简单的通过对象来自动生成。
因此还需要能够实现基于方法来发布API接口服务。
即在API快速开发平台能够进行API接口的自定义，详细的定义API接口的输入参数和输出参数信息。同时对于定义完成的接口实现和后台方法的绑定。
实现和JAR包里面的API接口的绑定
可以实现和一个JAR包里面方法或函数的绑定，将一个方法或函数发布为一个Http API接口方法。在当前很多公有云的云服务总线产品上可以看到这个实现方式。
实现和动态SQL的绑定
可以将定义的一个API接口方法和动态SQL进行绑定。其中动态SQL本身具体动态输入参数，这些输入参数和API接口定义中的输入进行数据映射。同时SQL语句查询的输出结果和API接口定义的输出字段进行映射。
如果动态SQL是插入或更新类，同样也可以通过参数化变量方式进行数据映射和绑定操作。
和存储过程进行绑定
一个数据库的存储过程，实际即是一个方法函数，因此可以将API接口定义的输入和输出和数据库存储过程的输入和输出进行映射绑定。
要注意的是针对不同的数据库存储过程schema信息获取和适配本身有差异，这也是在上图中构建一个独立的统一数据库适配层的原因。
规则处理
在API接口开发过程中，可以进行一些简单的规则处理。具体如下：
输入数据完整性校验，对输入数据进行完整性校验，其中包括场景的数据类型，长度，范围约束等，这些都是属于比较容易通过配置进行实现的内容。
数据项间规则处理，可以对多个数据项进行简单规则处理，其中包括了场景的数据映射，数据丰富，数据截取等。这些本身也是在主流的传统ESB总线产品中都支持的内容。
自定义脚本语言，对于API快速开发平台本身可以作为低代码开发平台的一个子类，因此如果能够支持自定义脚本语言进行规则处理，那么整体扩展性和灵活性也会得到大幅度提升。
消息头和输出预留，对于API开发平台发布的API接口，需要对输入消息头，输出的异常类型，异常编码，信息等字段进行提前约定。
在输入的消息头中往往包括了类似用户名，Token等用于访问安全校验的字段，也包括了类似路由，分页等相关扩展字段信息。对于输出字段，需要对返回的异常类型，编码，异常信息等进行约定。特别是涉及到数据CUD操作的时候，需要按约定的输出字段进行输出。
服务组合和编排
对于API开发平台还可以进一步提供服务组合和服务编排的能力。这个能力的实现也不适合放在API网关来完成，而是应该规划到API开发平台来实现。
服务组合编排是服务组合，服务组装等，希望通过服务编排能够完成这些事情，而不是简单的完成单一服务的设计和开发。即将多个原子服务组合或组装在一起，最终形成一个新的服务并提供的能力。我们举例来说明下。
比如存在A，B，C三个原子服务，我们通过服务编排形成一个新的D服务。
三个原子服务全部是查询服务，希望组装一个新服务，一次返回A，B，C三个服务查询结果
这个即我们说的服务组合能力，比如我们可以对合同基本信息查询，合同条款信息查询，合同执行信息查询三个基本原子服务进行组合，最终返回一个服务综合信息查询的服务，一次返回三个查询结果。
在这种场景下我们需要考虑查询结果是并行返回还是按层次返回即可。
二个查询类的原子服务，最终需要返回两个数据集关联查询的结果集
这个在微服务架构做了底层数据库拆分后经常会遇到，比如对于物料基本信息查询，和采购订单明细查询是在两个独立的数据库独立服务提供。而我们希望返回的查询结果集是物料编码，名称，型号，单位，价格，采购数量的复合结果集。
这种场景下往往一般都是在前端功能开发的时候进行组装，而实际上可以考虑是否可以在服务编排层解决这个问题，该问题写代码来解决容易，但是要做为可视化服务编排组态方式来做实际上有一定的难度。
对单个已有服务进行裁剪和丰富并形成一个新服务输出
这个暂时也将其纳入到服务编排的范畴，即仍然是输入服务，但是输出是提供了一个新服务。
即对单个已有的服务进行服务裁剪和丰富，比如对于输出结果过滤掉一些数据项，对于输入固定输入一些数据项等。这些简单的服务裁剪，丰富，或简单的数据转换可以在服务编排的时候完成，并提供一个新服务。
对多个原子服务进行流程式的前后串接并形成服务提供
这个是我们经常看到的一种服务编排场景，即A，B，C三个服务直接进行编排，即A服务的输出直接变为B服务的输入，B服务的输出又变为C服务的输出。如果仅仅是上面假设的这样，那么这种流程式的服务编排仍然很简单，也很容易去实现。
但是实际上的难点在于A服务的输出本身也需要作为C服务的输出，同时A，B服务的输出也可能是整体输出的一部分，这本身就加大了服务编排可视化设计的难度。
单一业务服务为主体服务，但是编排多个业务规则逻辑处理类服务
这也是经常会遇到的场景，比如我们在进行合同信息导入的时候，首先要调用合同有效性校验服务，同时还有调用预算信息检查和扣减服务进行相关的完整性和业务规则校验。在这些校验完成后再调用实际的合同信息导入服务，如果校验失败则直接返回失败结果。
这类服务编排往往也正是我们实际在进行前端功能开发时候服务进行组装的逻辑。
多个导入服务组装为一个导入服务合并导入并形成一个新服务
这个场景实际上和场景1是对应的，既然多个服务可以组合后形成组合结果返回，那么自然可以将多个导入服务合并为一个导入服务，一次性的完成数据导入。
比如有项目信息导入和项目WBS信息导入两个原子服务，那么我们就可以提供一个新的项目信息导入服务，一次完成项目基本信息和项目WBS信息的导入。
在这些场景里面可以看到，实际上服务编排就是服务串联，服务并联下的输入和输出合并，服务内容丰富和裁剪等常见场景。在一个理想的场景下，我们最希望实现的就是一个业务功能点的实现完全能够通过服务编排可视化设计方式来完成。
源代码导出
对于API快速开发平台，很难去实现复杂的业务规则编码。因此在存在复杂业务规则实现的时候仍然是建议开发人员自己开发代码来完成。因此整个平台应该提供源代码导出功能，导出的源代码应该直接能够编译通过，脱离API开发平台部署和运行。
对于导出的源代码，考虑到后续API接口变更的场景，建议是对扩展部分进行约定。
比如一个标准的API接口服务实现方法，可以在前后增加扩展处理。
//BeforeDo(); //ProcessAPI(); //AfterDo();
这样在接口实现前可以进行额外的业务规则处理和完整性校验，在接口返回数据前还可以对输出的数据进一步进行处理和加工。
微服务应用
可以将多个对象或多个API接口服务打包到一个微服务应用再进行部署和发布。因此在这里引入一个微服务集的概念，对微服务API进行打包处理。
打包完成的微服务可以导出为独立的JAR包进行部署，也可以直接在API开发平台进行托管部署。对于API开发平台本身应该对接到微服务运行平台。
