[从零开始’写’博客] - 框架整合及接口开发
框架整合及接口开发
- 框架整合
- 1. 配置数据源和mybatis
- 2. 整合Swagger2构建强大API文档
- 3. 整合log4j日志打印
- 关于使用Restful api
- 关于通用response响应内容
框架整合
1. 配置数据源和mybatis
数据源使用的*HikariCP（光）*，从这个名字就能看出它突出一个快，号称目前性能最强。Springboot2都已经将默认数据库连接池从tomcat改成hikariCP了。所以直接修改配置文件即可。
spring:
datasource: # 数据源的相关配置
type: com.zaxxer.hikari.HikariDataSource # 数据源类型：HikariCP
driver-class-name: com.mysql.jdbc.Driver # mysql驱动
url: jdbc:mysql://localhost:3306/blog?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true
username: root
password: password
hikari:
connection-timeout: 30000
minimum-idle: 5 # 最小连接数 5-10
maximum-pool-size: 20 # 最大连接数 20 和硬件配置有关，4核10个 8核20
auto-commit: true # 自动提交
idle-timeout: 600000 # 连接超时的最大时长（毫秒），超时则被释放（retired），默认:10分钟
pool-name: DateSourceHikariCP # 连接池名字
max-lifetime: 1800000
connection-test-query: SELECT 1
2. 整合Swagger2构建强大API文档
为减少程序员编写文档时间，提高生产力，swagger2应运而生。他可以帮助程序员在编写代码时自动生成文档。
- 添加maven依赖
io.springfox
springfox-swagger2
2.4.0
io.springfox
springfox-swagger-ui
2.4.0
com.github.xiaoymin
knife4j-spring-boot-starter
2.0.2
knife4j是为Java MVC框架集成Swagger生成Api文档的增强解决方案，提供更符合国人习惯的文档界面。
- 编写swagger2配置类
@Configuration
@EnableSwagger2
public class SwaggerConfig {
@Bean
public Docket createRestApi() {
return new Docket(DocumentationType.SWAGGER_2) // 指定api类型为swagger2
.apiInfo(apiInfo()) // 用于定义api文档汇总信息
.select()
.apis(RequestHandlerSelectors.basePackage("com.changzhen.blog.controller"))
.paths(PathSelectors.any())
.build();
}
private ApiInfo apiInfo() {
return new ApiInfoBuilder()
.title("blog 接口api") // 文档页标题
.contact(new Contact("博客发布平台",
"http://chzhlp.com",
"[email protected]")) // 联系人信息
.description("专为blog发布平台提供的api文档")
.version("0.0.1") // 文档版本号
.termsOfServiceUrl("http://chzhlp.com")
.build();
}
}
使用@EnableSwagger2开启swagger2
配置Docket bean，主要是扫描的包和接口信息
接着访问 {ip}:{port}/doc.html 出现下图则集成成功
[外链图片转存中…(img-XkaEN7gY-1591198077494)]
3. 整合log4j日志打印
- 移除springboot中默认日志
<exclusions>
<exclusion>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-loggingartifactId>
exclusion>
exclusions>
- 添加日志框架
<dependency>
<groupId>org.slf4jgroupId>
<artifactId>slf4j-apiartifactId>
<version>1.7.21version>
dependency>
<dependency>
<groupId>org.slf4jgroupId>
<artifactId>slf4j-log4j12artifactId>
<version>1.7.21version>
dependency>
- 在资源目录下
src/main/resources创建配置文件log4j.properties
log4j.rootLogger=DEBUG,stdout,file
log4j.additivity.org.apache=true
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.threshold=INFO
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
log4j.appender.file=org.apache.log4j.DailyRollingFileAppender
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.DatePattern='.'yyyy-MM-dd-HH-mm
log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
log4j.appender.file.Threshold=INFO
log4j.appender.file.append=true
log4j.appender.file.File=logs/blog-api/run.log
关于使用Restful api
Restful是目前最流行的 API 设计规范，用于 Web 数据接口的设计。设计时通常在uri中只能使用名词，因其代表资源故不能使用动词。通过http协议使用 GET 、POST、PUT、DELETE来操作资源。
1. GET — 获取资源
2. POST — 新建资源
3. PUT — 更新资源
4. DELETE — 删除资源
但是，在我们工作的时因为便利性而将设计规范弱化。通常只会只用两种，
GET用来获取资源POST用来修改资源
在设计URI的过程中如果按照设计规范，有时GET、PUT、DELETE会使用相同的URI，当前端人员对接接口时就会产生困惑。所以一般设计时也会使用一些动词，使接口的含义更加简单明了。
关于通用response响应内容
目前有两种格式的响应使用的比较多。一、所有请求都返回200 OK的状态码，在data中再次定义code，msg，data的内容，根据业务确定自己的状态码，前端根据获取到的内容进行下一步处理。二、所有返回都遵循http响应码根据响应码来判断错误，但是业务如果复杂了，状态码表达的含义可能还是不够。
目前我使用的是第一种方式，原因如下：
1. http响应码可能表达的含义不够，还是需要自定义响应码。
2. 目前接口对接人员水平参差不齐，可能我使用了状态码而对接人员并不清楚具体含义。
3. 自定义code时，只有定义文档清晰应该对接起来很方便。
4. 好多运营商和所谓智能浏览器会劫持你的非200请求。
我自定义的response如下，其中添加了一下常用的相应方法。使用起来还是比较方便的。
@Data
public class ApiJsonResponse {
private int code;
private String msg;
private Object data;
public ApiJsonResponse(int code, String msg, Object data) {
this.code = code;
this.msg = msg;
this.data = data;
}
public ApiJsonResponse() {
this.code = Status.SUCCESS.getCode();
this.msg = Status.SUCCESS.getStandardMessage();
}
public static ApiJsonResponse Message(int code, String msg) {
return new ApiJsonResponse(code, msg, null);
}
public static ApiJsonResponse Success(Object data) {
return new ApiJsonResponse(Status.SUCCESS.getCode(), Status.SUCCESS.getStandardMessage(), data);
}
public static ApiJsonResponse Error(Object data) {
return new ApiJsonResponse(Status.INTERNAL_SERVER_ERROR.getCode(), Status.INTERNAL_SERVER_ERROR.getStandardMessage(), data);
}
public static ApiJsonResponse ErrorMsg(String msg) {
return new ApiJsonResponse(Status.INTERNAL_SERVER_ERROR.getCode(),msg,null);
}
public static ApiJsonResponse Status(Status status) {
return new ApiJsonResponse(status.getCode(), status.getStandardMessage(), null);
}
public static ApiJsonResponse ok() {
return new ApiJsonResponse(Status.SUCCESS.code, Status.SUCCESS.standardMessage, null);
}
public static ApiJsonResponse ok(Object object) {
return new ApiJsonResponse(Status.SUCCESS.code, Status.SUCCESS.standardMessage, object);
}
public enum Status {
SUCCESS(200, "OK"),
BAD_REQUEST(400, "请求错误！"),
NOT_FOUND(404, "未找到该请求！"),
INTERNAL_SERVER_ERROR(500, "系统内部错误，请稍后再试"),
NOT_VALID_PARAM(40005, "参数错误"),
NOT_SUPPORTED_OPERATION(40006, "不支持此操作"),
NOT_LOGIN(50000, "账号未登录，请登录后重试");
private int code;
private String standardMessage;
Status(int code, String standardMessage) {
this.code = code;
this.standardMessage = standardMessage;
}
public int getCode() {
return code;
}
public void setCode(int code) {
this.code = code;
}
public String getStandardMessage() {
return standardMessage;
}
public void setStandardMessage(String standardMessage) {
this.standardMessage = standardMessage;
}
}
}
第二篇分应该就是这些了。太久没写了，本想的一鼓作气把博客上线后再慢慢梳理内容，可惜自己前端vue还是比较薄弱，耽误太长时间。过完年后有几个项目都很紧就把这博客这就放下了。最近想起差点羞的又把之前那篇删了，纠结半天最后还是考虑撸起袖子加油干吧，先写着之后发现有不对的地方再返回改吧。反正成长不就是一次次打脸的过程么。
准备工作基本就绪，下一篇应该会进入到coding。。。