Java Jersey 客户端和 Apache HTTP 客户端如何比较？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/18570206/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How do Jersey-client and Apache HTTP Client compare?
提问by carlspring
First of all, I'm not trying to start a flame-war here. I know Jersey sufficiently well, but have hardly used httpclient.
首先，我不是想在这里开始一场激烈的战争。我非常了解泽西岛，但几乎没有使用过 httpclient。
What are the key differences between jersey-client and Apache's httpclient? In what areas is one better than the other? Is there a good comparison chart somewhere? Which one performs better with larger files (say 2048 MB)?
jersey-client 和 Apache 的 httpclient 之间的主要区别是什么？在哪些方面一个比另一个好？某处有很好的比较图表吗？对于较大的文件（比如 2048 MB），哪一种表现更好？
Many thanks for your comments!
非常感谢您的评论！
采纳答案by Jk1
These two things probably should not be compared directly. Jersey is a REST-client, featuring full JAX-RS implementation, neat fluent API and a powerfull filter stack. Apache Http Client is a HTTP-client, perfect in managing low-level details like timeouts, complex proxy routes and connection polling. They act on a different levels of your protocol stack.
When you're using Jersey there is always some kind of HTTP client backend involved. Given no backend explicitly, Jersey will use HttpUrlConnectionas a default backend.
这两件事可能不应该直接比较。Jersey 是一个 REST 客户端，具有完整的 JAX-RS 实现、简洁流畅的 API 和强大的过滤器堆栈。Apache Http Client 是一个 HTTP 客户端，非常适合管理低级细节，如超时、复杂的代理路由和连接轮询。它们作用于协议栈的不同级别。当您使用 Jersey 时，总会涉及某种 HTTP 客户端后端。鉴于没有明确的后端，Jersey 将HttpUrlConnection用作默认后端。
Jersey with HttpUrlConnection backend example:
Jersey 与 HttpUrlConnection 后端示例：
Client client = Client.create();
WebResource webResource = client.resource("http://localhost:8080/path");
ClientResponse response = webResource.accept("application/json")
.get(ClientResponse.class);
Jersey with Apache Http Client backend example:
Jersey 与 Apache Http 客户端后端示例：
HttpClient apacheClient = HttpClientBuilder.create().build();
Client client = new Client(new ApacheHttpClient4Handler(apacheClient,
new BasicCookieStore(),
true));
WebResource webResource = client.resource("http://localhost:8080/path");
ClientResponse response = webResource.accept("application/json")
.get(ClientResponse.class);
Please note usage of Handler in the last example. This is a key integration abstraction for Jersey to incorporate and utilize various backends. First example uses URLConnectionClientHandlerdeep under the hood.
请注意上一个示例中 Handler 的用法。这是 Jersey 整合和利用各种后端的关键集成抽象。第一个示例使用URLConnectionClientHandler了引擎盖下的深处。
Speaking about performance and features it makes little sense to compare Apache Http Client with Jersey. One may want to compare different Jersey backends here, as Jersey itself is merely a wrapping API. I'd like to highlight some key differencies between HttpUrlConnection and Apache Http Client based on my own experience:
谈到性能和特性，将 Apache Http Client 与 Jersey 进行比较毫无意义。人们可能想在这里比较不同的 Jersey 后端，因为 Jersey 本身只是一个包装 API。我想根据我自己的经验强调 HttpUrlConnection 和 Apache Http Client 之间的一些主要区别：
HttpUrlConnection
HttpUrlConnection
- No external dependencies are necessary. This may be quite valuable on embedded or mobile platforms.
- Extremely well documented everywhere
- Has poorly designed API.
HttpUrlConnection-based implementation is difficult to maintain and extend. - Many features are configured through JVM properties, some of which may be non-reconfigurable during runtime.
- In some cases hopeless at handling timeouts. You may end up setting 10 different JVM properties for different timeouts and still get your connections hanging forever in some circumstances.
- Since Gingerbread is a recommendedhttp client API for Android.
- 不需要外部依赖。这在嵌入式或移动平台上可能非常有价值。
- 到处都有很好的记录
- 具有设计不佳的 API。
HttpUrlConnection基于的实现难以维护和扩展。 - 许多特性是通过 JVM 属性配置的，其中一些在运行时可能是不可重新配置的。
- 在某些情况下无法处理超时。您最终可能会为不同的超时设置 10 种不同的 JVM 属性，并且在某些情况下仍然会使您的连接永远挂起。
- 由于 Gingerbread 是Android推荐的http 客户端 API。
Apache Http Client
Apache Http 客户端
- For 3.X versions it's performance was somewhat similar to
HttpUrlConnection. Version 4.1 contains lots of performance enchancements and performs way better than it's counterpart - Quite good at managing connection and data read timeouts
- It's design follows Open/Closed Principle, so you can customize almost any part of HTTP processing with your own implementation. Examples: redirect strategies, retry strategies, custom cookie storages, interceptors for requests/responses, etc.
- Provides rich proxy support with customizable route builders for complex multy-proxy paths
- Has out of the box per-route connection pool. This may give a good performance benefit if SSL/TLS is used, especialy having hardware PKCS#11 tokens involved.
HttpUrlConnectionalso has an internal pooling, but you have no tools to customize what or when to pool, no monitoring facilities to check the pool state. - Features detailed logging
- 对于 3.X 版本，它的性能有点类似于
HttpUrlConnection. 4.1 版包含许多性能增强功能，并且比它的对应版本表现更好 - 非常擅长管理连接和数据读取超时
- 它的设计遵循开放/封闭原则，因此您可以使用自己的实现自定义 HTTP 处理的几乎任何部分。示例：重定向策略、重试策略、自定义 cookie 存储、请求/响应拦截器等。
- 通过可定制的路由构建器为复杂的多代理路径提供丰富的代理支持
- 具有开箱即用的每路由连接池。如果使用 SSL/TLS，这可能会带来良好的性能优势，尤其是涉及硬件 PKCS#11 令牌。
HttpUrlConnection也有一个内部池化，但你没有工具来定制什么或什么时候池化，没有监控工具来检查池状态。 - 具有详细的日志记录功能
Keep in mind, that it also possible to use other backends (e.g. for non-blocking clients) with Jersey if you have an appropriate com.sun.jersey.api.client.ClientHandlerimplementation.
请记住，如果您有适当的com.sun.jersey.api.client.ClientHandler实现，也可以将其他后端（例如用于非阻塞客户端）与 Jersey 一起使用。
