java - REST-API 错误响应的不同内容类型

Question

几周以来，我一直在使用 spring-mvc 开发 rest api。REST-API 工作正常，我几乎完成了最后一个关于特定错误对象错误处理的问题。

REST-API 使用 JSON 作为格式来序列化 Java 对象。当服务执行期间发生错误时，将创建一个特定的错误对象并将其发送回客户端。

当我的休息服务被标记为“produces=application/json”时，一切正常。但也有一些服务只需要使用“produces=text/plain”返回简单的文本。当这些服务之一发生错误时，Spring-MVC 将抛出 HttpMediaTypeNotAcceptableException。似乎是正确的，因为客户端要求内容类型为“text/plain”，但服务器响应为“application/json”。

你能告诉我这个问题的正确解决方案是什么吗？

1. 仅使用 JSON 作为响应内容类型，并始终将简单文本包装在一个特殊的类对象中。 => 在我看来不太像 REST，因为 REST 应该支持多种内容类型。

2. 每个提供“文本”的服务都将被标记为“produces=application/json;text/plain”，客户端也需要在“accept-header”中发送这两者。 => 这样做时，API 似乎支持同一资源的两种内容类型。但那是不对的。只有在出现错误的情况下，API 才会返回 JSON，否则它将始终为“文本”。

对我来说，这听起来像是一个非常特殊的 REST 问题，找不到关于该主题的相关问题。

Answer 1

我遇到了同样的问题，而且我对 REST 最佳实践有完全相同的问题。

我阅读的所有关于处理 API 响应错误的文章都使用 JSON。示例 here .

我不认为所有这些 API 总是将数据包装在 JSON 中。有时你只需要提供文件、文本或非 json 的东西......另外，我偶然发现了 RFC7807 ，它提出了一种使用 JSON 格式公开错误/问题的标准方法，甚至使用它自己的内容类型 application/problem+json。因此，我们可以放心地假设，为 HTTP 200 使用与 HTTP 错误代码不同的内容类型是一种很好的做法。

关于如何用Spring Framework来做，其实很简单。一旦您了解“produces ={}”基本上是一种说明您的响应将是某种类型的声明方式，您可以想象也可以通过编程方式设置您想要返回的类型。

这是一个示例 API，它应该返回 application/octet-stream(一个二进制文件)。

@GetMapping(path = "/1/resources/hello", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
public ResponseEntity<StreamingResponseBody> getFile(@RequestParam(value = "charset", required = false, defaultValue = "UTF-8") String charset) {
    return ResponseEntity.ok().body(outputStream -> outputStream.write("Hello there".getBytes(Charset.forName(charset))));
}

当它工作时，它将返回一个具有正确内容类型的文件。现在，如果你想处理错误情况(在这种情况下，一个错误的字符集参数)，你可以创建一个异常处理程序:

@ExceptionHandler(UnsupportedCharsetException.class)
public ResponseEntity<?> handleCharsetException(UnsupportedCharsetException e) {
    return ResponseEntity.badRequest().contentType(MediaType.APPLICATION_JSON_UTF8).body(new ErrorResponse("1", "Wrong charset"));
}

现在，错误案例也按预期工作:

GET http://localhost/1/resources/hello?charset=CRAP

HTTP/1.1 400 Bad Request
Connection: keep-alive
Transfer-Encoding: chunked
Content-Type: application/json;charset=UTF-8
Date: Mon, 25 Mar 2019 17:37:39 GMT

{
  "code": "1",
  "message": "Wrong charset"
}