java produces_java-在所有产生JSON的端点上使用@Produces(“...

出于Content Negotiation和HTTP协议正确性的目的,您应该始终声明@Produces和@Consumes批注(在类级别或方法级别).没有这些注释,结果将取决于客户端请求和服务器的默认行为(在不同的实现中可能有所不同),这将导致不可预测的模棱两可的结果.

通过这些注释,我们宣传可以生产和消费的媒体类型.在获取(GET)请求时,客户端应发送一个带有他们期望返回的资源的媒体类型的Accept标头.并且在创建请求(PUT,POST)时,客户端应发送一个Content-Type标头,告诉服务器它们正在发送的数据是哪种媒体类型.如果这些标头与广告服务器要处理的标头不匹配,则客户端将收到错误响应,告诉他们问题出在哪里；如果有Retrieve请求和不匹配的Accept标头,则响应为406 Not Acceptable.如果有Create请求和不匹配的Content-Type标头,则响应为415 Unsupported Media Type.

这就是内容协商的工作方式.为了确保我们的服务器行为符合客户的期望,我们应该声明我们可以在服务器上处理的内容.注释就是这样做的.

如前所述,当您不使用@Produces时,客户端告诉您需要更改响应类型.这是因为结果是将Content-Type响应标头设置为application / octet-stream,这是the answers here的结论.客户端使用Content-Type标头来确定如何处理响应.

最后一个示例是针对“检索”请求的.如果我们在创建端点上不使用@Consumes,那么很多其他事情都会出错.例如,我们有一个要接受JSON的端点,因此我们创建一个POJO来将JSON映射到.

@POST

public Response create(Customer customer) {}

为此,它取决于客户端在对application / json的请求上设置Content-Type标头.但是没有@Consumes批注,我们基本上是在宣传此终结点,以便能够接受任何媒体类型,这简直是荒谬的. @Consumes批注就像一个警卫说“如果您发送的数据类型不正确,您将无法通过”.但是,由于我们没有保护措施,因此所有数据都可以通过,并且结果是不可预测的,因为根据客户端将Content-Type设置为哪种类型,我们不知道MessageBodyReader1将处理实体主体的转换给客户.如果未选择正确的MessageBodyReader(将JSON转换为POPJO的MessageBodyReader),则很可能会导致异常,并且客户端将返回500 Internal Server Error,该错误与获取415 Unsupported Media无关.类型.

1.See chapter 8 and 9 of the Jersey docs.它将说明如何分别使用MessageBodyReader和MessageBodyWriter将实体转换为Java对象(反之亦然).