多些一些总没坏处

最新推荐文章于 2024-06-21 22:54:28 发布

kgh246810

最新推荐文章于 2024-06-21 22:54:28 发布

阅读量5.6k

点赞数

本文链接：https://blog.csdn.net/kgh246810/article/details/108631089

版权

一个后端接口大致分为四个部分组成：接口地址（url）、接口请求方式（get、post等）、请求数据（request）、响应数据（response）。如何构建这几个部分每个公司要求都不同，没有什么“一定是最好的”标准，但一个优秀的后端接口和一个糟糕的后端接口对比起来差异还是蛮大的，其中最重要的关键点就是看是否规范!

本文就一步一步演示如何构建起一个优秀的后端接口体系，体系构建好了自然就有了规范，同时再构建新的后端接口也会十分轻松。

所需依赖包
这里用的是SpringBoot配置项目，本文讲解的重点是后端接口，所以只需要导入一个spring-boot-starter-web包就可以了：

org.springframework.boot spring-boot-starter-web 本文还用了swagger来生成API文档，lombok来简化类，不过这两者不是必须的，可用可不用。

参数校验
一个接口一般对参数（请求数据）都会进行安全校验，参数校验的重要性自然不必多说，那么如何对参数进行校验就有讲究了。

业务层校验
首先我们来看一下最常见的做法，就是在业务层进行参数校验：

public String addUser(User user) {
if (user == null || user.getId() == null || user.getAccount() == null || user.getPassword() == null || user.getEmail() == null) {
return “对象或者对象字段不能为空”;
}
if (StringUtils.isEmpty(user.getAccount()) || StringUtils.isEmpty(user.getPassword()) || StringUtils.isEmpty(user.getEmail())) {
return “不能输入空字符串”;
}
if (user.getAccount().length() < 6 || user.getAccount().length() > 11) {
return “账号长度必须是6-11个字符”;
}
if (user.getPassword().length() < 6 || user.getPassword().length() > 16) {
return “密码长度必须是6-16个字符”;
}
if (!Pattern.matches("¹+@[a-zA-Z0-9_-]+(\.[a-zA-Z0-9_-]+)+$", user.getEmail())) {
return “邮箱格式不正确”;
}
// 参数校验完毕后这里就写上业务逻辑
return “success”;
}
这样做当然是没有什么错的，而且格式排版整齐也一目了然，不过这样太繁琐了，这还没有进行业务操作呢光是一个参数校验就已经这么多行代码，实在不够优雅。

我们来改进一下，使用Spring Validator和Hibernate Validator这两套Validator来进行方便的参数校验！这两套Validator依赖包已经包含在前面所说的web依赖包里了，所以可以直接使用。

Validator + BindResult进行校验
Validator可以非常方便的制定校验规则，并自动帮你完成校验。首先在入参里需要校验的字段加上注解,每个注解对应不同的校验规则，并可制定校验失败后的信息：

@Data
public class User {
@NotNull(message = “用户id不能为空”)
private Long id;

@NotNull(message = "用户账号不能为空")
@Size(min = 6, max = 11, message = "账号长度必须是6-11个字符")
private String account;

@NotNull(message = "用户密码不能为空")
@Size(min = 6, max = 11, message = "密码长度必须是6-16个字符")
private String password;

@NotNull(message = "用户邮箱不能为空")
@Email(message = "邮箱格式不正确")
private String email;

}
校验规则和错误提示信息配置完毕后，接下来只需要在接口需要校验的参数上加上@Valid注解，并添加BindResult参数即可方便完成验证：
@RestController
@RequestMapping(“user”)
public class UserController {
@Autowired
private UserService userService;

@PostMapping("/addUser")
public String addUser(@RequestBody @Valid User user, BindingResult bindingResult) {
    // 如果有参数校验失败，会将错误信息封装成对象组装在BindingResult里
    for (ObjectError error : bindingResult.getAllErrors()) {
        return error.getDefaultMessage();
    }
    return userService.addUser(user);
}

}
这样当请求数据传递到接口的时候Validator就自动完成校验了，校验的结果就会封装到BindingResult中去，如果有错误信息我们就直接返回给前端，业务逻辑代码也根本没有执行下去。

此时，业务层里的校验代码就已经不需要了：

public String addUser(User user) {
// 直接编写业务逻辑
return “success”;
}
现在可以看一下参数校验效果。我们故意给这个接口传递一个不符合校验规则的参数，先传递一个错误数据给接口，故意将password这个字段不满足校验条件：

{
“account”: “12345678”,
“email”: “123@qq.com”,
“id”: 0,
“password”: “123”
}
再来看一下接口的响应数据：

这样是不是方便很多？不难看出使用Validator校验有如下几个好处：

（1）简化代码，之前业务层那么一大段校验代码都被省略掉了。

（2）使用方便，那么多校验规则可以轻而易举的实现，比如邮箱格式验证，之前自己手写正则表达式要写那么一长串，还容易出错，用Validator直接一个注解搞定。（还有更多校验规则注解，可以自行去了解哦）

（3）减少耦合度，使用Validator能够让业务层只关注业务逻辑，从基本的参数校验逻辑中脱离出来。

使用Validator+ BindingResult已经是非常方便实用的参数校验方式了，在实际开发中也有很多项目就是这么做的，不过这样还是不太方便，因为你每写一个接口都要添加一个BindingResult参数，然后再提取错误信息返回给前端。

这样有点麻烦，并且重复代码很多（尽管可以将这个重复代码封装成方法）。我