首先先看一下HTTP中定义的响应码及其意义:
响应码
|
含义
|
100
|
继续
|
101
|
分组交换协议
|
200
|
OK
|
201
|
被创建
|
202
|
被采纳
|
203
|
非授权信息
|
204
|
无内容
|
205
|
重置内容
|
206
|
部分内容
|
300
|
多选项
|
301
|
永久地传递
|
302
|
找到
|
303
|
参见其他
|
304
|
未改动
|
305
|
使用代理
|
307
|
暂时重定向
|
400
|
错误请求
|
401
|
未授权
|
402
|
要求付费
|
403
|
禁止
|
404
|
未找到
|
405
|
不允许的方法
|
406
|
不被采纳
|
407
|
要求代理授权
|
408
|
请求超时
|
409
|
冲突
|
410
|
过期的
|
411
|
要求的长度
|
412
|
前提不成立
|
413
|
请求实例太大
|
414
|
请求URL太大
|
415
|
不支持的媒体类型
|
416
|
无法满足的请求范围
|
417
|
失败的预期
|
500
|
内部错误
|
501
|
未被使用
|
502
|
网关错误
|
503
|
不可用的服务
|
504
|
网关超时
|
505
|
HTTP版本未被支持
|
一、成功
从 200 到 399 为成功码,表示请求处理成功。
如果方法返回值不为null,则返回码是 200;如果返回值为 null 或者为 void,则返回码为 204,表示无内容。
二、错误
从 400 到 599 表示处理错误。
例如 404表示网页未找着;如果请求的期望的返回交换类型不对,则返回 406,表示不可接爱;如果请求的方法未找着,则返回 405,表示方法不允许,这个返回结果对于HEAD和OPTIONS请求方法例外,对于HEAD会试图去查找能处理相同URI的GET方法;对于OPTION,会返回一些自动生成的信息。
三、复杂的响应
对于不能简单处理的返回信息,则可以返回javax.ws.rs.core.Response对象:
Response对象不能直接创建,需要通过javax.ws.rs.core.Response.ResponseBuilder来创建:
ResponseBuilder是一个用来创建单个Response实例的工厂类, 首先将要创建的response对象的状态存起来,最后当状态设置完成了,就使用builder去初始化Response:
例如:
四、Cookie
JAX-RS使用了一个简单的类去表示一个cookie值,它就是javax.ws.rs.core.NewCookie:
要返回Cookie,只需要传入它到Response中:
五、状态类别
除了直接写数据外,JAX-RS定义了一个状态值的枚举类别:
每个Status的值都关联的到一个特定HTTP的返回值族,这个族由Status.Family标识。例如 100范围的值被认识是信息性的;200范围的是成功;300范围的也是成功,但是被重定向的;400是client错误;500是服务器错误。
Response.status()和ResponseBuilder.status()都接受一个Status值,例如:
六、javax.ws.rs.core.GenericEntity
当处理Response的返回对象(entity)时,如果是一个类似于MessageBodyWriter这样的支持泛型的对象,则问题来了: isWriteable()方法需要有泛弄的信息。然后不幸的是java的泛型信息只存在编译时,不存在运行时,因此没有一个简单的方法可以得到在运行时得到泛型的信息,因此MessageBodyWriter不知道如何输出对象。
为了解决这个问题,JAX-RS提供了一个帮助类 javax.ws.rs.core.GenericEntity 。例如:
GenericEntity也是一个泛型模板,只需要将输出entity的泛型信息加到它上,并且把对象做为一个参数传入即可。
七、javax.ws.rs.WebApplicationException
WebApplicationException是一个内置、非检测异常,支持传入Response对象或者状态码:
当JAX-RS碰到一个WebApplicationException抛出时,它就捕获这个异常,调用它的getResponse()方法去获取Response,发回给client端。 如果应用以一个状态码或者Response初始化了WebApplicationException,则这个状态码或者Response将被用来创建真正的HTTP响应;或者,会直接返回 500, “Internal Server Error“给客户端,例如:
这里如果没找着客户,会返回404错误
八、错误匹配
应用中可能有各种各样的,来自应用或者第三方包的异常,如果仅依赖于容器提供的错误处理方式,则可能灵活度不够: 捕获这些异常,然后包装到WebApplicationException中会让人觉得相当乏味。
这里的另外一种选择就是使用javax.ws.rs.ext.ExceptionMapper,这个对象知道怎么匹配一个抛出的异常到一个Repsonse对象上:
例如对于JPA有EntityNotFoundException:
注: ExceptionMapper的实现,必须加上@Provider注释
ExceptionMapper也支持异常层级关系,例如A 继承 B,如果找不到A的mapper,则会向上查找B的mapper。
最后ExceptionMapper使用JAX-RS的deployment API进行注册,可以用Application.