通过API开发平台构建微服务应用实例(三)

在上一章中我们对《供应商资料管理》微服务应用的底层数据模型设计已经完成，这一章我们将开始开发微服务应用的API和端点。
一、 首先对于数据实体的API能力发布，我们可以直接使用平台数据实体发布在线API的功能，这个功能可以发布对于数据实体的增删改查的基本API能力，且做过完整的事务处理。发布后的API是部署在Node-Red服务器上生成flow，对于Node-Red比较熟悉的开发人员也可以打开flow进行编排和二次开发。

可以配置请求路径、私有/公有、API分组(通过Token来控制访问权限)。

三个数据实体全部添加进入之后可以开始部署和发布在线API,部署和启用操作见下图红色选中操作，实现了在线一键部署和启用。

部署和启用完成之后我们来看一下在Node-Red中生成的API，我们通过下图中数据实体的编排操作(红色框中)来打开单个flow的编排设计界面。

从上图中可以看到根据数据实体我们生成了五个API端点，其中包括：查询所有供应商/查询单个供应商/新增单个供应商/更新单个供应商/删除单个供应商。我们对API端点使用平台提供的在线测试功能进行测试一下，首先测试新增单个供应商：
我们来自动构建新增供应商的JSON输入：

我们看到整个供应商信息的数据结构还是比较复杂的，数据层次可分为三层：
供应商基本信息
|----------供应商公司信息(1条)
|--------------供应商银行账号信息(2条)
|--------------供应商联系人信息(2条)
|----------供应商附件信息(2条)
我们在平台上使用此JSON调用新增供应商的API端口进行测试：

新增供应商API调用成功，我们先来看一下平台上的API调用日志信息：

可以看到平台上也成功记录了新增供应商API的调用记录，这个记录日志的功能目前我们是异步实现的，即如果记录日志出现问题也不会影响到API的正常调用返回。
最后我们来测一下供应商信息查询API的调用情况和查一下数据库中的数据，已检查数据是否真实写入了数据库：

数据库记录如下：

5个表已经全部新增入库，并且完成关联关系。其他的API端点我这里就不再一一测试。

二、 接下来继续回到供应商API开发这个话题上来，上面只是完成了《供应商信息》《供应商分类》《参数主数据》这三个业务实体的API发布，但我们实际工作当中也有可能存在只是对比如《供应商信息》中的联系人信息进行增删改查，这个时候我们的数据库已经存在有了《联系人信息》的数据表了，因此我们只需要针对数据表进行发布API即可，平台支持对于数据库中的表可以在线一键生成增/删/改/查(分页及排序)等API。下面是操作的界面：

选择数据库连接和表完成设计之后，再进行设计的部署启用，完成后如下图：

点击编排查看部署后的API流程及端点，可以看到针对Table的API生成了6个端点：

下面主要测试Table生成的两个API端点：
1、GET获取所有数据API端点

2、POST查询服务条件的记录排序并分页API端点

使用的查询条件：vendorcompanyID=2，CONTACT_NAME desc，0，2，如下图：

三、 在需求分析一章我们分析过，外部系统或者客户对于供应商的统计有自己的需求，我们的需求人员可能会根据客户的需求先整理一份文档，这份文档在经过评审确认之后需要交付到开发团队进行设计开发，开发团队对于文档的理解会存在偏差，导致频繁的沟通和代码不断变更。因此需要一种技术型的需求文档，这类文档可以在开发环节中复用并约束代码，能控制开发的技术实现和需求保持一致。这类文档就是我们API的规范文件，可以是YAML或者JSON格式。我们平台内置了两种规范编辑器，一种是Swagger的设计器，一种是参考开源产品并进行优化后的API规范设计器，Swagger设计器我们就不多说，下面主要使用API规范设计器来设计供应商统计类的API。

该API设计器有如下特点：
1、 标准化：遵守OpenAPI 3.0标准，向下兼容。
2、 结构化：对于API的端点、数据类型、输入/输出、操作等的定义都是以表单的形式，省去了自己写代码的烦恼。
3、 自动化：对于API规范的检查都是自动化的，系统会提示缺少的内容并要求补全。
4、 一致性：基于结构化的设计和YAML/JSON源码编辑的强一致性，可支持导出YAML/JSON文件。
对于第一章中的供应商统计API需求：
5、供应商统计分析的API：
5.1 统计当月新增供应商数量。
5.2 统计不同纳税标识的供应商数量。
5.3 统计最新创建的10个供应商列表。
我们来开始设计API规范，设计后内容如下：

从上图我们看到，针对需求的三个API路径设计如上，其中不同纳税标识的供应商数量有一个输入参数。设计完成后我们来看生成的YAML文件：

我们将其保存到平台中：

接下来选择该API规范进行设计开发，平台支持在线按步骤配置开发，以下为配置步骤：

完成后我们对配置的设计资源进行部署和启用，部署启用后查看该API流程和API端点如下图：

对这三个端点分别进行测试：

四、 最后一个API需求，比如外部系统想要《供应商资料管理》应用提供一个跨多个数据表的查询API(查询特定客户编码的供应商附件信息)。
那么使用到的SQL如下：
select a.* from vd_vendorinfovendorattainfo a,vd_vendorinfo b where a.vendorinfoID=b.vendorinfoID and b.CUSTOMER_NUMBER=#{custnum}
新增SQL -API服务设计：


在线进行测试返回结果：

五、 通过在API快速开发平台上进行API线上开发感觉确实很方便，我们可以看到基本上只用掌握最基本的需求编写能力和SQL编写能力，就能完全零代码把API发布出来。但是这不是最关键的，最关键的在于API在线发布之后前端和外部系统都测试完成准备上线了，但是API还是与开发平台绑在一起，对于很多企业来说，需要将API从开发平台上独立剥离出来，独立的打包部署实现容器化、负载均衡、网关代理、servicemesh等等，有可能还需要对API做一些二次的定制开发。平台考虑到现实的这些场景，还提供一个合并各类API，整体导出微服务程序包和微服务部署包的功能，我们接下来往下看：
选中我们《供应商资料管理》微服务应用中涉及到的API，其中数据实体API三个、规范API一个、TableAPI一个、SQLAPI一个：

我们点击导出部署及程序包：

然后等待………

导出之后生成程序包和部署包如下，可点击下载程序包和部署包：

我们先下载部署包直接运行：

平台默认指定Jar包的运行端口在8081，我们运行成功后打开8081端口的Swagger说明文件，swagger-ui.html：

可以看到，之前在API开发设计平台在线开发的API已经全部导出，我们拿获取全部供应商信息的API端点测试一下，发现和在线API返回的数据结构完全一致，这也是平台考虑的关键点之一(即在线API测试完之后，导出的微服务在调用时保证和在线的完全一致，避免的前端或者外部系统的二次测试工作)：

最后我们导出程序包大概来看一下生成代码的程序结构，平台是生成的JAVA代码，使用Springboot框架，集成了Mybatis和Swagger：

总结：从最开始的微服务需求分析->业务实体识别->数据实体识别和定义->API定义->API在线开发测试->导出微服务。我们可以看到整个过程一气呵成，当然平台的功能还远不止如此，我们正在将API自动化测试、存储过程发布API、API灵活的编排组合、分布式事务支持、异步API发布等功能全部在平台上实现，未来将形成开源和商业两个版本，也欢迎对这块感兴趣的人员与我们沟通合作。