为什么使用Jersey?
刚开始使用Jersey的时候,我也会有疑问,Spring家族已经很完善,为什么要用Jersey,但是后来做项目多了就感受到两者的差异.
1. Jersey是JAX-RS标准的参考实现,是Java领域中开发REST式web/服务的"正统"工具,Spring属于自成一派,不是严格意义上的实现REST,但是springMVC已经支持RestFul风格,这个对我来说并不影响我开发项目.
2. 这点很关键,就是spring家族的庞大,导致spring依赖很重,打包占用较大的空间,Jersey相比就比较轻,反而更适合项目开发
如何使用Jersey?
这个官方文档已经很详细了,包括配置注解等等,Jerey的使用我通常是和SpringBoot搭配使用,所以这里我只讲我遇到的官网找不到的内容,就是Jersey接受json对象转pojo.
首先Jersey是支持Json的,官网是这样介绍的,JSONP等等格式的JSON都支持,这里我用的Jackson.要想Jersey支持Json肯定要配置一个Json配置,并在JerseyConfig里面注册.
JacksonConfig配置
JerseyConfig配置
/**
* 配置注册
*/
public JerseyConfig() {
// 开启api请求日志记录
super.register(new LoggingFeature(null, Level.INFO, null, null));
// 开启json to bean转换
super.register(CustomJsonProvider.class);
scan(basePackage);
}
配置好了后,就开始Json to Bean的转换了,然后就是带代码实现:
Consumes输入Json格式 Produces输入Json格式
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
@Path("/selectBook")
@POST
public ResponseDTO selectBook( Book book){
return new ResponseDTO(Code.SUCCESS.value(), Message.SUCCESS.value());
}
//Book 是一个实体Bean
这样可以实现接受Json类型,然后转换成book对象,但是假如说你还有token或者其他参数要输入怎么办.(这里是一个坑,因为Param不能有太多的类型注解,比如@QueryParam ,@HeaderParam,@PathParam 等等,这样Json to Bean的转换就会出错,或者是接收不到参数等等问题)这里可以实现用HttpServletRequest @Context HttpServletRequest request 这个来在逻辑代码内接受参数:
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
@Path("/selectBook")
@POST
public ResponseDTO selectBook( @Context HttpServletRequest request
,Book book){
String token = request.getHeader("token");
// ....代码
return new ResponseDTO(Code.SUCCESS.value(), Message.SUCCESS.value());
}
这样就可以实现Json接受参数,然后转换成实体对象了!
如果你也需要这样做的,不妨可以试试.