webresource_Jersey WebResource

webresource_Jersey WebResource –标头不附加

webresource

昨天，在使用Jersey WebResource类进行HTTP调用时遇到了一个奇怪的问题：似乎我设置的标头在执行HTTP调用时被忽略了。提前阅读。

我试图实现的目标是调用REST Api从我们的应用程序中获取一些数据。为此，我使用了Jersey客户端，显然，我还必须转发接收到的授权令牌，以便在目标应用程序上对用户进行身份验证。不了解详细的Jersey Api，我做了以下事情（不完全是，但根据本文内容进行了说明）：

WebResource resource = Client.create(new DefaultClientConfig()).resource("http://myapp.org/api/v1/data");
resource.accept(MediaType.APPLICATION_JSON);
resource.type(MediaType.APPLICATION_JSON);
resource.header(HttpHeaders.AUTHORIZATION, "Negotiate " + token);return resource.get(String.class);

但是， Negotiate令牌没有被附加，至少这是我在收到“ 401授权被拒绝”响应时明确注意到的。在我的Apache上记录HTTP请求进一步强调了我的假设。

作为尝试，我将代码稍微重写为以下内容

return Client.create(new DefaultClientConfig()).resource("http://myapp.org/api/v1/data").accept(MediaType.APPLICATION_JSON).type(MediaType.APPLICATION_JSON).header(HttpHeaders.AUTHORIZATION, "Negotiate " + token).get(String.class);

..嘿，它成功了！ WTF？这是怎么回事

建造者模式

最初看起来很疯狂，但是当您看看如何在com.sun.jersey.api.client.WebResource类上实现accept(...)时，这会变得更加清晰：

...
@Override
public Builder accept(String... types) {return getRequestBuilder().accept(types);
}
...

每次您都会获得一个新的Builder对象！这就是为什么它不起作用。因此，您不必像上面的错误版本那样编写它：

WebResource resource = Client.create(new DefaultClientConfig()).resource("http://myapp.org/api/v1/data");WebResource.Builder builder = resource.accept(MediaType.APPLICATION_JSON);
builder.type(MediaType.APPLICATION_JSON);
builder.header(HttpHeaders.AUTHORIZATION, "Negotiate " + token);return builder.get(String.class);

注意，第一个调用resource.accept()返回Builder对象，随后对type()和header()任何调用都直接在该Builder实例上进行。

您甚至可以反转调用顺序，例如先调用resource.type(..) ，然后accept等等。为什么？因为WebResource.Builder和WebResource本身都实现相同的接口RequestBuilder ，只是WebResource的实现创建了一个新的Builder对象，而Builder的实现实际上将传递的信息添加到了元数据集合中。

结论

Builder模式是通过隐藏实现细节（尤其是在Java中）来简化对象实例创建的一种常用方法。通常，您调用一系列向您的对象添加信息的方法，以最终调用build()方法，该方法返回所需的实例。 WebResource类完全隐藏了这一点。现在，由于已经很长时间没有使用Java进行编码了，所以我不确定WebResource实现Builder模式的方式是否是常见的方式，但是我发现它会分心并且可能导致讨厌的错误。至少，我花了几个小时才能弄清楚为什么我的身份验证方案不起作用。