Question

例如，我们为SpittleController添加一个新的处理器方法，它会提供单个Spittle对象：

在这里，通过id参数传入了一个ID，然后根据它调用Repository的findOne()方法，查找Spittle对象。处理器方法会返回findOne()方法得到的Spittle对象，消息转换器会负责产生客户端所需的资源表述。

非常简单，对吧？我们没办法让它更棒了。它还能更好吗？

如果根据给定的ID，无法找到某个Spittle对象的ID属性能够与之匹配，findOne()方法返回null的时候，你觉得会发生什么呢？

结果就是spittleById()方法会返回null，响应体为空，不会返回任何有用的数据给客户端。同时，响应中默认的HTTP状态码是200（OK），表示所有的事情运行正常。

但是，所有的事情都是不对的。客户端要求Spittle对象，但是它什么都没有得到。它既没有收到Spittle对象也没有收到任何消息表明出现了错误。服务器实际上是在说：“这是一个没用的响应，但是能够告诉你一切都正常！”

现在，我们考虑一下在这种场景下应该发生什么。至少，状态码不应该是200，而应该是404（Not Found），告诉客户端它们所要求的内容没有找到。如果响应体中能够包含错误信息而不是空的话就更好了。

Spring提供了多种方式来处理这样的场景：

使用@ResponseStatus注解可以指定状态码；

控制器方法可以返回ResponseEntity对象，该对象能够包含更多响应相关的元数据；

异常处理器能够应对错误场景，这样处理器方法就能关注于正常的状况。

在这个方面，Spring提供了很多的灵活性，其实也不存在唯一正确的方式。我不会用某一种固定的策略来处理所有的错误或涵盖所有的场景，而是会向读者展现多种修改spittleById()的方法，以应对Spittle无法找到的场景。

使用ResponseEntity

作为@ResponseBody的替代方案，控制器方法可以返回一个ResponseEntity对象。ResponseEntity中可以包含响应相关的元数据（如头部信息和状态码）以及要转换成资源表述的对象。

因为ResponseEntity允许我们指定响应的状态码，所以当无法找到Spittle的时候，我们可以返回HTTP 404错误。如下是新版本的spittleById()，它会返回ResponseEntity：

像前面一样，路径中得到的ID用来从Repository中检索Spittle。如果找到的话，状态码设置为HttpStatus.OK（这是之前的默认值），但是如果Repository返回null的话，状态码设置为HttpStatus.NOT_FOUND，这会转换为HTTP 404。最后，会创建一个新的ResponseEntity，它会把Spittle和状态码传送给客户端。

注意这个spittleById()方法没有使用@ResponseBody注解。除了包含响应头信息、状态码以及负载以外，ResponseEntity还包含了@ResponseBody的语义，因此负载部分将会渲染到响应体中，就像之前在方法上使用@ResponseBody注解一样。如果返回ResponseEntity的话，那就没有必要在方法上使用@ResponseBody注解了。

我们在正确的方向上走出了第一步，如果所要求的Spittle无法找到的话，客户端能够得到一个合适的状态码。但是在本例中，响应体依然为空。我们可能会希望在响应体中包含一些错误信息。

我们重试一次，首先定义一个包含错误信息的Error对象：

然后，我们可以修改spittleById()，让它返回Error：

现在，这个方法的行为已经符合我们的预期了。如果找到Spittle的话，就会把返回的对象以及200（OK）的状态码封装到ResponseEntity中。另一方面，如果findOne()返回null的话，将会创建一个Error对象，并将其与404（Not Found）状态码一起封装到ResponseEntity中，然后返回。

你也许觉得我们可以到此结束这个话题了。毕竟，方法按照我们期望的方式在运行。但是，还有一点事情让我不太舒服。

首先，这比我们开始的时候更为复杂。涉及到了更多的逻辑，包括条件语句。另外，方法返回ResponseEntity<?>感觉有些问题。ResponseEntity所使用的泛型为它的解析或出现错误留下了太多的空间。

不过，我们可以借助错误处理器来修正这些问题。

处理错误

spittleById()方法中的if代码块是处理错误的，但这是控制器中错误处理器（error handler）所擅长的领域。错误处理器能够处理导致问题的场景，这样常规的处理器方法就能只关心正常的逻辑处理路径了。

我们重构一下代码来使用错误处理器。首先，定义能够对应SpittleNotFound-Exception的错误处理器：

@ExceptionHandler注解能够用到控制器方法中，用来处理特定的异常。这里，它表明如果在控制器的任意处理方法中抛出SpittleNotFoundException异常，就会调用spittleNotFound()方法来处理异常。

至于SpittleNotFoundException，它是一个很简单异常类：

现在，我们可以移除掉spittleById()方法中大多数的错误处理代码：

这个版本的spittleById()方法确实干净了很多。除了对返回值进行null检查，它完全关注于成功的场景，也就是能够找到请求的Spittle。同时，在返回类型中，我们能移除掉奇怪的泛型了。

不过，我们能够让代码更加干净一些。现在我们已经知道spittleById()将会返回Spittle并且HTTP状态码始终会是200（OK），那么就可以不再使用ResponseEntity，而是将其替换为@ResponseBody：

当然，如果控制器类上使用了@RestController，我们甚至不再需要@ResponseBody：

鉴于错误处理器的方法会始终返回Error，并且HTTP状态码为404（Not Found），那么现在我们可以对spittleNotFound()方法进行类似的清理：

因为spittleNotFound()方法始终会返回Error，所以使用ResponseEntity的唯一原因就是能够设置状态码。但是通过为spittleNotFound()方法添加@ResponseStatus(HttpStatus.NOT_FOUND)注解，我们可以达到相同的效果，而且可以不再使用ResponseEntity了。

同样，如果控制器类上使用了@RestController，那么就可以移除掉@ResponseBody，让代码更加干净：

在一定程度上，我们已经圆满达到了想要的效果。为了设置响应状态码，我们首先使用ResponseEntity，但是稍后我们借助异常处理器以及@ResponseStatus，避免使用ResponseEntity，从而让代码更加整洁。

似乎，我们不再需要使用ResponseEntity了。但是，有一种场景ResponseEntity能够很好地完成，但是其他的注解或异常处理器却做不到。现在，我们看一下如何在响应中设置头部信息。