magic-api 快速接口开发

magic-api 是一个基于Java的接口快速开发框架，编写接口将通过magic-api提供的UI界面完成，自动映射为HTTP接口。

1，引入magic-api-spring-boot-starter依赖

org.ssssssss

magic-api-spring-boot-starter

1.7.1

2，application.yml 中配置

magic-api:

#配置web页面入口

web: /magic/web

resource:

# location: /data/magic-api

type: database # 配置接口存储方式，这里选择存在数据库中

table-name: magic_api_file # 数据库中的表名

3，启动服务，访问magic-api web页面

http://127.0.0.1:8035/magic-test/magic/web

1，RequestParam

GET http://localhost:9999/xxx/xxx?name=abc&age=49

这样的URL参数magic-api 会自动将name和age映射为同名变量

2，表单参数

POST http://localhost:9999/xxx/xxx

name=abc&age=49

这样的表单参数magic-api 也会自动将name和age映射为同名变量。

3，Request Header参数获取

magic-api 会对所有RequestHeader统一封装为一个名为header的变量 如要获取 token 可以通过header.token 来获取。

4，POST请求的Request Body参数获取

{

"name"侍源: "magic-api"

}

如要获取name属性 则可通过 body.name 来获取

5，Path参数获取

主要是针对URL定义为http://localhost:9999/user/{id} 的类似接口

如要获取path路径上的id可通过path.id 或 id来获取

6，Cookie，Session参数获取

可搏卖以通过cookie.xxx，session.xxx来获取

1，#{} 注入参数，${} 拼接参数

作用和mybatis用法一致

id = #{id}

id=${id}

2，动态SQL参数

通过?{condition,expression}来实现动态拼接SQL，如果条件成立则拼接后部分内容SQL中，与mybatis中的if标签基本一致

return db.select("select * from sys_user ?{id,where id = #{id}}")

相当于mybatis中的

3，Mybatis 语法支持

1.6.0以后的版本支持Mybatis语法

*** 作入口 db.table('table_name')

1，insert

return db.table('sys_user').insert({ user_name : '李富贵', role : 'admin'})

// insert into sys_user(user_name,role) values('李老银态富贵','admin')

2，update

return db.table('base_dict').primary('code').update({ code: 'insertTerst', name : '测试insert'})

//update base_dict set name = ? where code = ?

3，save

用法和insert相似

return db.table('sys_user').primary('id', uuid()).save({user_name: '李富贵'})

// insert into sys_user(id,user_name) values('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx','李富贵')

4，select，page，where

return db.table('sys_user').select()

return db.table('sys_user').page()

return db.table('sys_user')

.where()

.like('user_name','%李富贵%')

.eq('role','admin')

.select()

yml中配置分页参数

magic-api:

page-config:

size: size # 页大小的请求参数名称

page: page # 页码的请求参数名称

default-page: 1 # 未传页码时的默认首页

default-size: 10 # 未传页大小时的默认页大小

自动分页

使用yml中配置的分页参数

return db.page("""select * from base_dict_detail""")

手动分页

跳过前3条记录，然后取5条

return db.page("""select * from base_dict_detail""",5,3)

自定义分页参数获取

实现 PageProvider接口，复写getPage方法 {

public Page getPage(RuntimeContext runtimeContext) {

long page = 2

long pageSize = 3

return new Page(pageSize, (page - 1) * pageSize)

}

此模式会覆盖yml的配置内容

目前内置了三种状态码，分别为 执行成功(1)，参数验证失败(0)，以及系统异常(-1)

自定义状态码

magic-api:

response-code-config:

success: 200 #执行成功的code值

invalid: 400 #参数验证未通过的code值

exception: 500 #执行出现异常的code值

默认返回格式

{

"code": 1, // 状态码

"message": "success", // 状态说明

"data": ..., // 返回的数据内容

"timestamp": 1629610503506, // 服务器时间

"executeTime": 1 // 执行时间

}

自定义返回格式

magic-api:

response: |- #配置JSON格式，格式为magic-script中的表达式

{

code: code,

message: message,

data,

timestamp,

requestTime,

executeTime,

}

自定义结构配置

实现ResultProvider接口，重写buildResult方法

引入swagger依赖

在yml文件中配置

magic-api:

swagger-config:

version: 1.0.0

description: magic测试文档

title: magic测试

name: 配置化实现

location: /v2/api-docs/magic-api/swagger2.json

Magic-api通过springboot自动配置的方式配置了resource,dataSource,interceptor等内容。

在服务启动时，生成MagicConfiguration注入容器时，通过mappingHandlerMapping.registerAllMapping()来注册所有映射(即在界面上配置的接口请求地址和接口的实际处理类、方法的映射)。映射关系注册到handleMapping中，并在内存中通过ConcurrentHashMap来缓存映射关系

接口调用时，在DispatcherServlet中通过url去寻找handler,找到magic-api的统一处理RequestHandler以及处理方法invoke。

在invoke中根据请求方法和路径获取接口信息封装在ApiInfo中，然后进行参数的验证封装。实际脚本的执行，以及对返回结果的包装

以上是一个最简单的Springboot程序（2.0.3版本）示例，也是我们最通用的写法，但其中其实封装这一系列复杂的功能 *** 作，让我们开始逐步进行分析。

首先这里最重要的必然是注解 @SpringBootApplication

@SpringBootApplication 注解由几个注解复合组成，其中最主要的就是 @SpringBootConfiguration 、 @EnableAutoConfiguration 和 @ComponentScan 这三个。

其中的 @ComponentScan 是spring的原生注解， @SpringBootConfiguration 虽然是springboot中的注解，但其实质就是包装后的 @Configuration ，仍然拆孙册是spring中的注解，用于代替xml的方式管理配置bean

@EnableAutoConfiguration 的定义如上，这里最凯碰重要的注解是 @Import （ @AutoConfigurationPackage 注解的实现也是基于 @Import ），借助 @Import 的帮助，将所有符合自动配置条件的bean定义加载到IoC容器中。关于 @EnableAutoConfiguration 注解后续涉及到时会再详细说明。这里我们先回到启动类的 run 方法从头分析初始化流程。

可以看到'run'方法最终调用的是 new SpringApplication(primarySources).run(args) ，这里首先创建了 SpringApplication 对象，然后调用其 run 方法

这里主要是为 SpringApplication 对象进行初始化，这里要专门提一下的是 webApplicationType 和 getSpringFactoriesInstances 。

它用来标识我们的应用是什么类型的应用，来看一下 deduceWebApplicationType() 方法的实现

其返回值是 WebApplicationType 类型的枚举类，其值有 NONE 、 SERVLET 、 REACTIVE 三种，分别对应非WEB应用，基于servlet的WEB应用和基于reactive的WEB应用。

这里的核心是 SpringFactoriesLoader.loadFactoryNames(type, classLoader) 方法，来看一下

重点关注一下 loadSpringFactories(classLoader) 做了什么

这里的 FACTORIES_RESOURCE_LOCATION 定义为 META-INF/spring.factories ，因此该方法会扫描所有包下的该文件，将其解析成map对象并缓存到 cache 中以避免旅宏重复加载，springboot包下该文件的部分片段如下

从这里可以看出， setInitializers((Collection) getSpringFactoriesInstances( ApplicationContextInitializer.class)) 和 setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class))分别对应设置的是上述这些类。

解析完成后调用 createSpringFactoriesInstances(type, parameterTypes, classLoader, args, names) 处理解析结果，生成对应的实例，源码如下

这里的核心是通过 ClassUtils.forName(name, classLoader) 方法，以反射的方式生成类实例 instanceClass 。由此可以看出 SpringFactoriesLoader.loadFactoryNames(type, classLoader) 的作用就是将 META-INF/spring.factories 中配置的内容进行实例化的工厂方法类，具备很强的扩展性，与SPI机制有异曲同工

的效果。

看完 SpringApplication 的初始化，接着跳回 run 方法继续分析

这里挑其中比较重要的几个方法进行分析

通过 getOrCreateEnvironment() 方法创建容器环境

可以看到 environment 存在则不会重复创建，当应用类型为servlet时创建的是 StandardServletEnvironment 对象，否则创建 StandardEnvironment 对象。

接着来看 configureEnvironment(environment, applicationArguments.getSourceArgs())

configurePropertySources(environment, args) 加载启动命令行的配置属性，来看一下实现

这里的 MutablePropertySources 对象用于存储配置集合，其内部维护了一个 CopyOnWriteArrayList 类型的list对象，当默认配置存在时，会向该list的尾部插入一个 new MapPropertySource("defaultProperties", this.defaultProperties) 对象。

接着来看 configureProfiles(environment, args)

这里主要做的事情就是获取 environment.getActiveProfiles() 的参数设置到 environment 中，即 spring.profiles.active 对应的环境变量。

最后来看一下 listeners.environmentPrepared(environment)

这里的 listeners 就是之前通过 META-INF/spring.factories 注册的所有listeners，后面我们先以其中最重要的 ConfigFileApplicationListener 做为例子进行分析，接着来看 listener.environmentPrepared(environment)

可以看到这里创建了一个 ApplicationEnvironmentPreparedEvent 类型的事件，并且调用了 multicastEvent 方法，通过该方法最终会调用到listener的 onApplicationEvent 方法，触发事件监听器的执行。

接下来具体看一下 ConfigFileApplicationListener 的 onApplicationEvent 方法做了什么

可以看到当监听到 ApplicationEnvironmentPreparedEvent 类型的事件时，调用 onApplicationEnvironmentPreparedEvent( (ApplicationEnvironmentPreparedEvent) event) 方法

可以看到这里通过 loadPostProcessors() 方法加载了 META-INF/spring.factories 中的所有 EnvironmentPostProcessor 类到list中，同时把 ConfigFileApplicationListener 自己也添加进去了。接着遍历list中所有对象，并执行 postProcessEnvironment 方法，于是接着来看该方法

这里的核心是 new Loader(environment, resourceLoader).load() ，这里的 Loader 是一个内部类，用于处理配置文件的加载，首先看一下其构造方法

可以看到这里的 resourceLoader 又是通过 SpringFactoriesLoader 进行加载，那么来看看 META-INF/spring.factories 中定义了哪些 resourceLoader

从名字就可以看出来， PropertiesPropertySourceLoader 和 YamlPropertySourceLoader 分别用于处理.properties和.yml类型的配置文件。

接着来看看 load() 方法做了什么

initializeProfiles() 进行了 profiles 的初始化，默认会添加 null 和 default 到 profiles 中， null 对应配置文件application.properties和application.yml， default 对应配置文件application-default.yml和application-default.properties，这里的 null 会被优先处理，由于后处理的会覆盖先处理的，因此其优先级最低。

接着来看 load(profile, this::getPositiveProfileFilter, addToLoaded(MutablePropertySources::addLast, false)) 方法

这里重点是通过 getSearchLocations() 获取配置文件的路径，默认会获得4个路径

接着会遍历这些路径，拼接配置文件名称，选择合适的yml或者properties解析器进行解析，最后将结果添加到 environment 的 propertySources 中。

可以看到这里也是根据 webApplicationType 的取值，分别创建不同的返回类型。

这里的 sources 装的就是我们的启动类，然后通过 load(context, sources.toArray(new Object[0])) 方法进行加载

来看一下 loader 是如何被加载的

经过一系列调用之后最终由 load(Class<?>source) 方法执行，这里比较有趣的是当Groovy存在时居然是优先调用Groovy的方式进行加载，否则才走 this.annotatedReader.register(source) 方法将启动类注册到 beanDefinitionMap 中。

这个 refresh() 方法相当重要，尤其是 invokeBeanFactoryPostProcessors(beanFactory) ，这是实现spring-boot-starter-*(mybatis、redis等)自动化配置的关键部分，后续再详细讲解。

至此Springboot的启动流程已经大体分析完了，也了解了配置文件和启动类分别是是如何被加载的，但仍有两个问题待解，一是Springboot的核心思想约定大于配置是如何做到的，二是Springboot的各种spring-boot-starter-*是如何发挥作用的，这两个问题留待后续文章继续分析。

script在很多场州敬景下都有使用到，我们这次来看下

注意：本篇文章所有脚本，lang为painless

在不同的上下文中，获取文档字段使用的语法是不同的。

注：↑表示这一行跟上一行是一样的

例子：自定义processor脚本

例子：为文档1的count加上 *** 作岁好数

例子：通过脚本增加字段

例子：查询城市是北京的

例子：自定义算分

例子：将原字段拼接为一个新的格式化之后的字段

例子：自定义排序规则

例子：scripted_metric，自定义脚本指标统计

大部分情况我们会将脚本保存到节点中，那要如何 *** 作呢？

例子：增加热门城市的热度

使用保存的脚本进行更新

注意：上面乎迹铅所有的inline脚本我们都可以保存在节点中，只是看场景而已。

es 会将脚本（inline和stored）缓存起来，可在elasticsearch.yml文件中做出更改

---