关于springboot:看看人家那后端-API-接口写得那叫一个优雅

43次阅读

共计 2333 个字符,预计需要花费 6 分钟才能阅读完成。

公众号:MarkerHub,网站:https://markerhub.com

作者:里奥 ii

起源:r6d.cn/tEvn

在挪动互联网,分布式、微服务流行的明天,当初我的项目绝大部分都采纳的微服务框架,前后端拆散形式,(题外话:前后端的工作职责越来越明确,当初的前端都称之为大前端,技术栈以及生态圈都曾经十分成熟;以前后端人员瞧不起前端人员,那当初后端人员要重新认识一下前端,前端曾经很成体系了)。

个别零碎的大抵整体架构图如下:

须要阐明的是,有些小伙伴会回复说,这个架构太简略了吧,太 low 了,什么网关啊,缓存啊,消息中间件啊,都没有。因为老顾这篇次要介绍的是 API 接口,所以咱们聚焦点,其余的模块小伙伴们自行去补充。

接口交互

前端和后端进行交互,前端依照约定申请 URL 门路,并传入相干参数,后端服务器接管申请,进行业务解决,返回数据给前端。

针对 URL 门路的 restful 格调,以及传入参数的公共申请头的要求(如:app_version,api_version,device 等),老顾这里就不介绍了,小伙伴们能够自行去理解,也比较简单。

着重介绍一下后端服务器如何实现把数据返回给前端?

返回格局

后端返回给前端咱们个别用 JSON 体形式,定义如下:

{  
 #返回状态码  
 code:integer,    
 #返回信息形容  
 message:string,  
 #返回值  
 data:object  
}

CODE 状态码

code 返回状态码,个别小伙伴们是在开发的时候须要什么,就增加什么。

如接口要返回用户权限异样,咱们加一个状态码为 101 吧,下一次又要加一个数据参数异样,就加一个 102 的状态码。这样尽管可能照常满足业务,但状态码太凌乱了

咱们应该能够参考 HTTP 申请返回的状态码

:上面是常见的 HTTP 状态码:200 - 申请胜利  
301 - 资源(网页等)被永恒转移到其它 URL  
404 - 申请的资源(网页等)不存在  
500 - 外部服务器谬误

咱们能够参考这样的设计,这样的益处就把谬误类型归类到某个区间内,如果区间不够,能够设计成 4 位数。

#1000~1999 区间示意参数谬误  
#2000~2999 区间示意用户谬误  
#3000~3999 区间示意接口异样  
 

这样前端开发人员在失去返回值后,依据状态码就能够晓得,大略什么谬误,再依据 message 相干的信息形容,能够疾速定位。

Message

这个字段绝对了解比较简单,就是产生谬误时,如何敌对的进行提醒。个别的设计是和 code 状态码一起设计,如

再在枚举中定义,状态码

状态码和信息就会一一对应,比拟好保护。

Data

返回数据体,JSON 格局,依据不同的业务又不同的 JSON 体。

咱们要设计一个返回体类 Result

管制层 Controller

咱们会在 controller 层解决业务申请,并返回给前端,以 order 订单为例

咱们看到在取得 order 对象之后,咱们是用的 Result 构造方法进行包装赋值,而后进行返回。小伙伴们有没有发现,构造方法这样的包装是不是很麻烦,咱们能够优化一下。

好看优化

咱们能够在 Result 类中,退出静态方法,一看就懂

那咱们来革新一下 Controller

代码是不是比拟简洁了,也好看了。

优雅优化

下面咱们看到在 Result 类中减少了静态方法,使得业务解决代码简洁了。但小伙伴们有没有发现这样有几个问题:

1、每个办法的返回都是 Result 封装对象,没有业务含意
2、在业务代码中,胜利的时候咱们调用 Result.success,异样谬误调用 Result.failure。是不是很多余
3、下面的代码,判断 id 是否为 null,其实咱们能够应用 hibernate validate 做校验,没有必要在办法体中做判断。

咱们最好的形式间接返回实在业务对象,最好不要扭转之前的业务形式,如下图

这个和咱们平时的代码是一样的,十分直观,间接返回 order 对象,这样是不是很完满。

那实现计划是什么呢?

实现计划

小伙伴们怎么去实现是不是有点思路,在这个过程中,咱们须要做几个事件

1、定义一个注解 @ResponseResult,示意这个接口返回的值须要包装一下
2、拦挡申请,判断此申请是否须要被 @ResponseResult 注解
3、外围步骤就是实现接口 ResponseBodyAdvice 和 @ControllerAdvice,判断是否须要包装返回值,如果须要,就把 Controller 接口的返回值进行重写。

注解类

用来标记办法的返回值,是否须要包装

拦截器

拦挡申请,是否此申请返回的值须要包装,其实就是运行的时候,解析 @ResponseResult 注解

此代码核心思想,就是获取此申请,是否须要返回值包装,设置一个属性标记。

重写返回体

下面代码就是判断是否须要返回值包装,如果须要就间接包装。这里咱们只解决了失常胜利的包装,如果办法体报异样怎么办?解决异样也比较简单,只有判断 body 是否为异样类。

怎么做全局的异样解决,篇幅起因,老顾这里就不做介绍了,只有思路理分明了,自行革新就行。

重写 Controller

在控制器类上或者办法体上加上 @ResponseResult 注解,这样就 ok 了,简略吧。到此返回的设计思路实现,是不是又简洁,又优雅。

总结

这个计划还有没有别的优化空间,当然是有的。如:每次申请都要反射一下,获取申请的办法是否须要包装,其实能够做个缓存,不须要每次都须要解析。当然整体思路理解,小伙伴们就能够在此基础下面自行扩大。谢谢!!!

举荐浏览

太赞了,这个 Java 网站,什么我的项目都有!https://markerhub.com

这个 B 站的 UP 主,讲的 java 真不错!

太赞了!最新版 Java 编程思维能够在线看了!

正文完
 0