最近经历了几次面试,总会被问到java开发如何开发一个借口。无奈只是java小白一个最终都被pass掉了,因此今天写一篇博客总结一下最近学到的知识。
在移动互联网,分布式、微服务盛行的今天,现在项目绝大部分都采用的微服务框架,前后端分离方式。牵扯到前后端分离,自然就离不开对接,交互,而交互最好的方式莫过于通过API接口实现了。
前端和后端进行交互,前端按照约定请求的URL路径,并传入相关参数,后端服务器接收请求,进行业务处理,返回数据给前端。
针对URL路径的restful风格,以及传入参数的公共请求头的要求(如:app_version,api_version,device等),据说比较简单,笔者还没了解,无奈太菜,小伙伴们可以自行去了解。
这里主要介绍一下后端服务器如何实现把数据返回给前端
后端返回给前端我们一般用JSON体方式,它的定义如下
{
#返回状态码
code:integer,
#返回信息描述
message:string,
#返回值
data:object
}
CODE状态码
code状态码我们当然想返回什么就返回什么,但是这样做的结果就是状态码太过凌乱,有可能自己就弄混。所以我们可以参考HTTP请求返回的状态码
下面是常见的HTTP状态码:
200 - 请求成功
301 - 资源(网页等)被永久转移到其它URL
404 - 请求的资源(网页等)不存在
500 - 内部服务器错误
我们可以参考这样的设计,这样的好处就把错误类型归类到某个区间内,如果区间不够,可以设计成4位数。
#1000~1999 区间表示参数错误
#2000~2999 区间表示用户错误
#3000~3999 区间表示接口异常
这样前端开发人员在得到返回值后,根据状态码就可以知道,大概什么错误,再根据message相关的信息描述,可以快速定位。
再在枚举中定义,状态码
状态码和信息就会一一对应,比较好维护。
Data
返回数据体,JSON格式,根据不同的业务又不同的JSON体。
我们要设计一个返回体类Result
@Data
public class Result implements Serializable {
private Integer code;
private String message;
private Object data;
public Result(ResultCode resultCode,Object data){
this.code = resultCode.code();
this.message = resultCode.message();
this.data = data;
}
}
我们会在controller层处理业务请求,并返回给前端,以order订单为例
@RestController
@RequestMapping("/orders")
public class OrderController {
@Autowired
private OrderService orderService;
@GetMapping("{id}")
public Result getOrder(@PathVariable("id") Integer id){
Order order = orderService.getOrderById(id);
Result result = new Result(ResultCode.SUCCESS,order);
return result;
}
}
我们看到在获得order对象之后,我们是用的Result构造方法进行包装赋值,然后进行返回。小伙伴们有没有发现,构造方法这样的包装是不是很麻烦,我们可以优化一下。
我们可以在Result类中,加入静态方法,一看就懂
@Data
public class Result implements Serlizable {
//省略..........
//返回成功
public static Result success(){
Result result = new Result();
result.setResultCode(ResultCode.SUCCESS);
return result;
}
//返回成功
public static Result success(Object data){
Result result = new Result();
result.setResultCode(ResultCode.SUCCESS);
result.setData(data);
return result;
}
//返回失败
public static Result failure(ResultCode resultCode){
Result result = new Result();
result.setResultCode(resultCode);
return result;
}
//返回失败
public static Result failure(ResultCode resultCode,Object data){
Result result = new Result();
result.setResultCode(resultCode);
result.setData(data);
return result;
}
这时再改变一下Controller
@RestController
@RequestMapping("/orders")
public class OrderController {
@Autowired
private OrderService orderService;
@GetMapping("{id}")
public Result getOrder(@PathVariable("id") Integer id){
if(id == null){
return Result.failure(ResultCode.PARAM_IS_INVALID);
}
Order order = orderService.getOrderById(id);
return Result.success(order);
}
}
代码是不是比较简洁了,也美观了。
上面我们看到在Result类中增加了静态方法,使得业务处理代码简洁了。但小伙伴们有没有发现这样有几个问题:
1、每个方法的返回都是Result封装对象,没有业务含义
2、在业务代码中,成功的时候我们调用Result.success,异常错误调用Result.failure。是不是很多余
3、上面的代码,判断id是否为null,其实我们可以使用hibernate validate做校验,没有必要在方法体中做判断。
下期引子,思路在这里,小伙伴们可以先自己想一下解决方法