知遇网spring boot 前后端分离项目--开发规范V1.0

本文地址：https://blog.csdn.net/weixin_43432772/article/details/89315232
作者：知遇网-黄明；最后修改日期：2019-4-15

本文中所有代码在svn目录下

boot开发规范)

一、 ResTful API 风格

网上博客地址：https://www.jianshu.com/p/320cee90391f

HTTP方法

GET（SELECT）：从服务器取出资源（一项或多项）。
POST（CREATE）：在服务器新建一个资源。
PUT（UPDATE）：在服务器更新全部资源（客户端提供改变后的完整资源）。
PATCH（UPDATE）：在服务器更新部分资源（客户端提供改变的属性）。
DELETE（DELETE）：从服务器删除资源。

响应状态码

100~199：信息状态码，代表请求已被接受，需要继续处理。

200~299：成功状态码，代表请求已成功被服务器接收、理解、并接受。

300~399：重定向状态码，代表需要客户端采取进一步的操作才能完成请求。

400~499：客户端错误状态码，代表了客户端看起来可能发生了错误，妨碍了服务器的处理。

500~599：服务器错误状态码，代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。

特别注意几个常用的状态码：

200 请求已成功，请求所希望的响应头或数据体将随此响应返回。

400 1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。 　　
2、请求参数有误。

500 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。

二、常见的文本、邮件、不能为空等，spring boot自带注解可以快速实现：@Valid注解和BindingResult验证请求参数的合法性并处理校验结果。（此块内容在开发中应用较为广泛，认真学习）

例子：创建用户时，接口参数中用户名不能为空。@NotBlank(message = “用户名不能为空”)

提示：在请求方法的字段上加上@valid注解时，以上的注解将生效。如果请求接口的参数无法通过校验，将返回状态码为400（此处认真理解学习）

使用postman测试结果如下：

常见的注解如下图：

已经能够按照RestFulApi的方式返回400的错误信息，但是返回的异常信息不是很友好（有很多乱七八糟的字段，与我们自定义的400错误信息json结构不一致，那么前端接受到此json时还需特殊处理），并且错误信息也没有进行统一的维护。所以 我们重构注解的异常方法，让其错误信息按着我们统一格式返回。

第一步：定义错误消息枚举

第二步：在dto中加入相应注解并在message中传入定义的枚举

第三步： Postman测试结果

第四步： 前端接收到后端返回的json对象，做统一的拦截处理，判断 status==400弹出统一的提示（提示框为警告黄色状态，提示语为返回json对象中“error”信息）

总结：使用此方式，代码精简、错误码与消息能够统一维护、返回客户端的状态更加明确，是符合RestFulApi的最佳实践。

三、默认的校验注解只能够满足一小部分校验要求。例如需要校验一个字段是否唯一，就无法通过默认的注解完成。还有可能有更多的复杂校验逻辑，比如西仓项目需要校验一个询价单中所有的物料是否已经报价等（此处的开发很关键，每个项目都有大量这样的代码）

常见的实现思路有二种，①重构校验注解（自定义注解）；②在service层【特别注意代码逻辑不允许写在controller层】代码逻辑判断后做异常抛出。我们采用后者，所以重点介绍与掌握第二点的写法。
如：根据一个用户id查找此用户，如果用户不存在返回此用户不存在。
Service层代码实现：

public Object getUser(String id)
    {
   
        User currentInstance = userRepository.findOne(id);
        //判断获取的用户为空
if (currentInstance == null)
        {
   
Map<String, Object> map;
            map.put