在所有JSON生成endpoint上使用@produces（“application/JSON”）是一种好的做法吗？

Question

我们开始对前端代码使用的内部RESTendpoint使用Jersey/JAX-RS。必须返回结果的endpoint总是发送JSON对象。

出于调试目的，我们使用firefox restclient扩展。直到最近，我只需输入URL并单击send，就会得到显示为JSON的内容。

但是当我今天早上这样做的时候，FF扩展返回并告诉我必须将响应类型更改为二进制(BLOB)。这样做会导致显示编码字符串而不是JSON。

问题：真的那么简单吗？还是有很好的技术理由不这么做？

Answer 1

为了内容协商和HTTP协议的正确性，您应该始终声明@produces和@consumes注释（无论是在类级别还是方法级别）。如果没有这些注释，结果将依赖于客户机请求和服务器的默认行为（在不同的实现中可能有所不同），这将导致不可预测和不明确的结果。

有了这些注释，我们就可以宣传我们可以生产和消费的媒体类型。在Retrieve(GET)请求上，客户端应该发送Accept标头，其中包含它们期望返回的资源的媒体类型。在创建请求(PUT、POST）时，客户端应该发送content-type标头，告诉服务器它们发送的数据是哪种媒体类型。如果这些头与服务器广告要处理的内容不匹配，那么客户机将返回错误响应，告诉他们问题所在；对于Retrieve请求和不匹配的Accept标头，响应将是406不可接受。对于创建请求和不匹配的content-type标头，响应将是415不支持的媒体类型。

这就是内容协商的工作原理。为了确保我们的服务器按照客户机期望的行为，我们应该声明我们可以在服务器上处理什么。注释就是这样做的。

正如您所提到的，当您停止@produces时，客户机告诉您需要更改响应类型。这是因为结果是content-type响应头被设置为application/octet-stream，这就是本文答案的结论。客户端使用content-type标头来确定如何处理响应。

最后一个示例用于检索请求。如果我们在创建endpoint上不使用@consumes，就会出现许多不同的问题。例如，我们有一个希望接受JSON的endpoint，所以我们创建一个POJO来映射JSON。

@POST
public Response create(Customer customer) {}

要做到这一点，取决于客户机在对application/json的请求中设置content-type标头。但是如果没有@consumes注释，我们基本上是在宣传这个endpoint能够接受任何媒体类型，这太荒谬了。@consumes注释的作用就像一个警卫，说“如果不发送正确类型的数据，就不能通过”。但是由于我们没有保护，所有数据都可以通过，结果是不可预测的，因为根据客户机将Content-Type设置为什么，我们不知道MessageBodyReader¹将如何处理从实体主体到Customer的转换。如果没有选择正确的MessageBodyReader（将JSON转换为POPJOs的那个），那么很可能会导致异常，客户机将返回一个500内部服务器错误，这不像得到一个415不受支持的媒体类型那么具体。

_{1。参见泽西岛文件第8章和第9章。它将解释如何分别使用MessageBodyReader和MessageBodyWriter将实体主体转换为Java对象（反之亦然）。}