RESTFul设计风格（三）
往期回顾：
最近几年，前后端分离特别流行。前后端分离后，涉及到的第一个问题就是对接。前台提交、接收参数，后台接收、返回参数，都涉及到接口文档。接口文档，不要小看，它在开发中为前后端沟通，起着决定性的作用，能不能高效的沟通，就看它了。
接口文档，如果用人工来写，那绝对是体力活，累死人的体力活。还记得有一个项目，采用的是前后端分离，那个对接文档写的，一个头两个大，吐了很多次。前台编码和后台编码又是两路人员，接口变更后，文档很难及时同步，本来测试好的功能，突然某一天坏掉了，调查个问题也要踢半天的足球、打一天的太极，时间都消耗在沟通和写文档上面了。
这种痛苦的记忆，终身难忘。JAVA开发语言生成在线文档，这种智能的事情，在很久之前就可以做了。可是在那个团队，还依旧用人工来码机械式的文档，痛呀。
现在开始一个新项目，在文档方面，痛改前非，一定要一键生成，而且要把文档生成的漂漂亮亮的。
在网上搜索一下，生成文档的插件多如牛毛，有收费的，有免费的。除了生成文档，还有一个重要问题，那就是后台返回给前台参数一定要规范，怎么看着别人家的返回参数就是那么规范呢？自己曾经写的返回参数类，怎么看都不规范。这个看似不规范的类，可是团队成员开会讨论的结果呀，大家的成果物呀，呀呀呀呀呀。
回归到RESTFul设计规范，在返回参数上面多看了一眼，咦，规范已经帮忙定义好了，可以自己拿来用，原来如此，不用再重复发明轮子了。其实，这是Spring提供的ResponseEntity,估计已经存在一段时间了，只是现在才看到，拿来就用，看看好不好用吧。
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
/**
* 测试类
* @author 程就人生
*
*/
@RestController
public class TestController {
@GetMapping("/test")
public ResponseEntity<String> test(){
String str = "Hello world~!";
//定义头部消息
HttpHeaders headers = new HttpHeaders();
headers.add("success", "true");
//返回到前端
return new ResponseEntity<>(str, headers, HttpStatus.OK);
}
}
看看调试的结果吧，
图-1
图-2感觉上还是不错的，达到了自己想要的效果，如果此时在Controller层里报异常，是否还能返回到前台呢，这是我比较关心的，不管正常异常，前端都会收到反馈，成功的时候在success里面接收，失败的时候在error或exception里面接收，这才算规范！
可以的哦，只需添加一个类，就可以把异常信息返回给前台。
import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestControllerAdvice;
/**
* Controller增强类，捕捉Controller层的异常，并返回给前台
* @author 程就人生
*
*/
@RestControllerAdvice
public class MyControllerAdvice {
/**
* 捕捉Controller里面的所有异常
* @param ex
* @return
*/
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public Map<String,Object> exception(RuntimeException ex){
Map<String,Object> messageMap = new HashMap<String,Object>();
messageMap.put("code", "500");
messageMap.put("message", ex.getMessage());
return messageMap;
}
}
代码写好了，在测试类里，增加一个参数id，id不为1时抛出一个异常，能不能返回给前台。
@GetMapping("/test/{id}")
public ResponseEntity<String> test(@PathVariable int id){
String str = "Hello world~!";
//定义头部消息
HttpHeaders headers = new HttpHeaders();
if(id !=1 ){
throw new RuntimeException("aaaaaa");
}else{
headers.add("success", "true");
}
//返回到前端
return new ResponseEntity<>(str, headers, HttpStatus.OK);
}
测试结果如下图，
图-3
可以看到，这时前台接收到了一个状态码和异常。有了这个类，在Controller里面调用service层时，就不怕Service层处理业务逻辑时再抛出异常，影响Controller层的返回了。另外还可以对增强类再扩展一下，对异常进行分类，细化异常，统一处理。
今天的这个Controller增强类，可以简化不少Service层的异常捕捉，是不是感觉又省了不少力气呢。
