1.Spring 4.0引入了@RestController注解,能够在这个方面给我们提供帮助。如果在控制器上使用@RestController来代替@Controller的话,Spring将会为该控制器
的所有处理方法应用消息转换功能,不必为每个方法都添加@ResponseBody了。
Controller写法如下
这两个方法都没有使用@ResponseBody注解,因为控制器使用@RestController,所以它的方法返回的对象将会通过消息转换机制,产生客户端所需的资源表述。
2.提供资源之外的其它内容
@ResponseBody提供了一个很有用的方式,能够将控制器返回的java对象转换为发送客户端的资源表述
实际上,将资源表述发送给客户端只是整个过程的一部分。一个好的REST API不仅能够在客户端和服务器之间传递资源,它还能够给客户端提供额外的元数据,帮助客户端理解资源或者在请求中出现了什么情况。
2.1发送错误信息到客户端
如果方法会返回null,响应体为空,不会返回任何有用的数据给客户端。同时,响应中默认的HTTP状态码是200(OK),表示所有的事情运行正常。
但是,所有的事情都是不对的。客户端要求的对象,但是它什么都没有得到。它既没有收到对象信息也没有收到任何消息表明出现了错误。服务器实际上是在说:“这是一个没用的响应,但是能够告诉你一切都正常!
Spring提供了多种方式来处理这样的场景:
*使用@ResponseStatus注解可以指定状态码;
*控制器方法可以返回ResponseEntity对象,该对象能够包含更多响应相关的元数据;
*异常处理器能够应对错误场景,这样处理器方法就能关注于正常的情况
使用ResponseEntity
作为@ResponseBody的替代方案,控制器方法可以返回一个ResponseEntity对象。ResponseEntity中可以包含响应相关的元数据以及药转换成资源表述的对象
因为ResponseEntity允许我们指定响应的状态码,所以当无法找到对象的时候可以返回404错误
这个方法没有使用@ResponseBody注解。除了包涵响应头信息、状态码以及负载以外,ResponseEntity还包含了@ResponseBody的语义。
spittleById()方法中的if代码块是处理错误的,但这是控制器中错误处理器(error handler)所擅长的领域,错误处理器能够导致问题的场景,这样常规的处理器
方法就只能关心正常的逻辑处理路径了。