疯狂咕咕的卷卷毛来了,这次我们来封装一个用于规范前后端交互传递消息和数据的类。
(其实这招是我跟大哥偷师的,它的主页在这里:地址。大家快去滴滴他)
说点铺垫
这次的操作针对的是在前后端交互过程中信息和数据传递的问题。
在前后端的交互过程中,从后台获取数据一直是交互的核心需求之一。
通常情况下,我们习惯于将返回的数据按照json的格式解析成为字符串,然后将这个字符串作为真正的数据返回。
由于spring提供的responseBody
注解,可以使方法返回的对象默认处理为Json的格式
更进一步的,在ResponseBody
基础上,spring还提供了集ResposeBody
和controller
于一体的RestController
,表示这整个controller中的方法返回值都按照responseBody的方式处理。这使得在编写接口时可以直接将需要的数据以对象的形式返回,这大大减少了繁琐的操作,提高了开发效率。
例如,如果该接口需要根据用户id获取用户信息:
@RestBody
@RequestMapping("user")
public class UserController{
@RequestMapping("getById")
public User getById(String userId){
User user = new User();
user.setId(userId);
user.setName("张三");
return user;
}
}
此时,带上需要查询的用户id访问这个接口就会获得预设的用户数据:
获取用户集合也不在话下:
@RestBody
@RequestMapping("user")
public class UserController{
@RequestMapping("getList")
public List<User> getList(){
List<User> list = new ArrayList();
list.add(new User("1", "张三"));
list.add(new User("2", "李四"));
list.add(new User("3", "王五"));
return list;
}
}
当然,这篇文章的重点不是讲解RequestBody怎么使用,而是想在这些例子的基础上进行进一步的讨论:既然ResponseBody这么方便,那么直接返回数据对象能够满足所有接口的需求吗,或者说,所有接口都可以写成这种格式吗?
是,但也不全是
为什么这么矛盾的说呢?因为这样直接写法的接口有一些问题:
- 首先,直接返回数据传递的信息量是不够的,缺少对错误的处理能力,至少应该包括此次业务处理的结果,如果有错误应该包含错误信息。
- 其次,这样实现方式不够统一和规范,不便于接口的维护。如果需求条件或者返回内容有少许变动,则前后端都需要修改。
交互须规范
为了解决这个问题,我们可以规定约定一个前后端传递数据的统一对象格式,这个对象应该至少包含以下信息
- 处理状态码(前后端自行约定)
- 处理结果(包含错误信息或者成功提示)
- 数据
表示成为Json格式可以是:
{
"code":...,
"message":...,
"data":...
}
例如,将上面根据id获取用户的结果包装成这个规范的格式:
{
&#