为了内容协商和HTTP协议正确性，您应该 始终 声明@Produces和@Consumes注释（在类级别或方法级别）。没有这些注释，结果将取决于客户端请求和服务器的默认行为（在不同的实现中可能有所不同），这将导致不可预测的模棱两可的结果。
通过这些注释，我们可以 宣传 可以生产和使用的媒体类型。在获取（GET）请求时，客户端应发送一个Accept标头，其中包含他们期望返回的资源的媒体类型。并且在创建请求（PUT，POST）时，客户端应发送一个Content- Type标头，告诉服务器它们发送的数据是哪种媒体类型。如果这些标头与广告服务器要处理的标头不匹配，则客户端将收到错误响应，告诉他们问题出在哪里；如果有Retrieve请求和不匹配的Accept标头，则响应将是406 Not Acceptable。对于创建请求和不匹配的Content- Type标头，响应将为415不支持的媒体类型。
这就是内容协商的工作方式。为了确保我们的服务器行为符合客户的期望，我们应该声明我们可以在服务器上处理的内容。注释就是这样做的。
正如您提到的，当您离开时@Produces，客户端告诉您您需要更改响应类型。这是因为结果是将Content-Type响应标头设置为application/octet-stream，这就是这里的答案所得出的结论。客户端使用Content- Type标头来确定如何处理响应。
最后一个示例是针对“检索”请求的。如果我们@Consumes在“创建”端点上放弃使用，那么很多不同的事情都会出错。例如，我们有一个要接受JSON的端点，因此我们创建一个POJO来将JSON映射到。
@POST
public Response create(Customer customer) {}
为此，取决于客户端将Content- Type请求上的标头设置为application/json。但是没有@Consumes注释，我们基本上是在广告此端点以使其能够接受 任何 媒体类型，这简直是荒谬的。该@Consumes注释就像一个后卫说：“如果你不发送正确的数据类型，你可以不通过”。但是由于我们没有保护，所以所有数据都被允许通过，并且结果是不可预测的，因为取决于客户端设置的对象Content- Type，我们不知道MessageBodyReader1将处理从实体主体到的转换Customer。如果正确MessageBodyReader 如果未选择（将JSON转换为POPJO的选项），则很可能会导致异常，并且客户端将返回500 Internal Server Error，该错误与获取415 Unsupported Media Type一样不具体。
1.请参阅Jersey文档的第8和9章。它将解释如何分别使用MessageBodyReader和将实体主体转换为Java对象（反之亦然）MessageBodyWriter。
602392714
清零编程群