Jersey Client 2.19不会在错误的状态代码上引发异常

Question

我正在使用jersey-client 2.19构建Rest Client ：

public ReleaseEntity createRelease(ReleaseEntity newRelease, int workspaceId) {

    Releases wrapper = new Releases();
    wrapper.setData(Arrays.asList(newRelease));

    WebTarget target = client.target(urlPrefix)
            .path(AgmUrls.getReleasesUrl(workspaceId));

    wrapper = target
            .request()
            .accept(MediaType.APPLICATION_JSON)
            .post(Entity.entity(wrapper, MediaType.APPLICATION_JSON))
            .readEntity(Releases.class);

    return wrapper.getData().get(0); 
} 

客户端在constructor初始化

this.client = ClientBuilder.newClient();

问题是，在响应不佳的情况下， post调用不会引发异常，无论是explicit还是runtime 。

我应该手动执行此操作，还是缺少某些内容？

Answer 1

这个问题已经过时，但是最好防止其他人重复同样的错误...

代替

result = target
            .request()
            .accept(MediaType.APPLICATION_JSON)
            .post(Entity.entity(input, MediaType.APPLICATION_JSON))
            .readEntity(Releases.class);

具有post(entity)返回一个Response在其上调用readEntity ，最好使用重载post(entity, responseType) ，这将在Error-Statuscodes上引发WebApplicationException 。

// throws runtime exception derived from WebApplicationException
// on error-statuscodes
result = target
            .request()
            .accept(MediaType.APPLICATION_JSON)
            .post(Entity.entity(input, MediaType.APPLICATION_JSON), Releases.class);

JAX-RS中的每个http方法都有这样的重载方法，可以读取Responses或制表对象。 在任何情况下，强烈建议读取表示对象以消耗潜在的响应主体。

// consumes response as string and guarantees to close the http call.
// A no-arg delete(); would be a potential leak!
target.request().delete(String.class); 

不幸的是，当必须读取响应头时，仍然需要读取Response而不是表示对象。

Answer 2

该框架不应引发异常。 用户应根据自己的意愿处理响应。 任何客户端都是一样的。 Response对象将包含处理响应所需的所有上下文，但您认为合适。

因此，您应该首先获得Response

Response response = target
         .request()
         .accept(MediaType.APPLICATION_JSON)
         .post(Entity.entity(wrapper, MediaType.APPLICATION_JSON));

然后您可以检查状态

int status = response.getStatus();

然后处理状态

if (status == 200) {
    wrapper = response.readEntity(Releases.class);
    ...
} else { 
    handleOtherStatus();   
}

如果您没有首先获得Response ，那么您将不知道实际的问题是什么，因为readEntity(...)将失败（因为它不是您所期望的主体），并引发另一个异常。 如果您想告诉用户实际的问题是什么，至少可以使用Response来解决。