Jersey-client和Apache HTTP Client如何比较？ [英] How do Jersey-client and Apache HTTP Client compare?

问题描述

首先，我不打算在这里开始一场火焰战争。我非常了解Jersey，但很少使用httpclient。

First of all, I'm not trying to start a flame-war here. I know Jersey sufficiently well, but have hardly used httpclient.

jersey-client和Apache的httpclient之间的主要区别是什么？哪个区域比另一个好？在某处有一个很好的比较图表吗？对于较大的文件（比如2048 MB），哪一个表现更好？

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是一个REST客户端，具有完整的JAX-RS实现，简洁流畅的API和强大的过滤器堆栈。 Apache Http Client是一个HTTP客户端，非常适合管理超时，复杂代理路由和连接轮询等低级细节。它们作用于协议栈的不同级别。
当你使用Jersey时，总会涉及某种HTTP客户端后端。如果没有明确的后端，Jersey将使用 HttpUrlConnection 作为默认后端。

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 HttpUrlConnection as a default backend.

泽西与HttpUrlConnection后端示例：

Jersey with HttpUrlConnection backend example:

Client client = Client.create();
WebResource webResource = client.resource("http://localhost:8080/path");
ClientResponse response = webResource.accept("application/json")
                                     .get(ClientResponse.class);

泽西与Apache Http客户端后端示例：

Jersey with Apache Http Client backend example:

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);

请注意上一个示例中Handler的用法。这是Jersey的一个关键集成抽象，可以整合和利用各种后端。第一个示例深入了解 URLConnectionClientHandler 。

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 URLConnectionClientHandler deep under the hood.

谈到性能和功能，将Apache Http Client与Jersey进行比较毫无意义。人们可能想在这里比较不同的泽西后端，因为泽西岛本身只是一个包装API。我想根据自己的经验强调HttpUrlConnection和Apache Http Client之间的一些关键差异：

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:

HttpUrlConnection

• 不需要外部依赖项。这在嵌入式或移动平台上可能非常有价值。


• 到处都记录得非常好


• API设计不佳。 基于HttpUrlConnection 的实现难以维护和扩展。


• 许多功能都是通过JVM属性配置的，其中一些可能是非在运行时可重新配置。


• 在某些情况下无望处理超时。您可能最终为不同的超时设置10个不同的JVM属性，并且在某些情况下仍然可以永久保持连接。


• 因为Gingerbread是推荐适用于Android的http客户端API。

• 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 recommended http client API for Android.

Apache Http客户端

• 对于3.X版本，它的性能有点类似于 HttpUrlConnection 。版本4.1包含许多性能增强并且表现优于对手


• 非常擅长管理连接和数据读取超时


• 它的设计遵循打开/关闭原则，因此您可以使用自己的实现自定义HTTP处理的几乎任何部分。示例：重定向策略，重试策略，自定义cookie存储，请求/响应的拦截器等。


• 为复杂的多代理路径提供可自定义路由构建器的丰富代理支持


• 具有开箱即用的每路径连接池。如果使用SSL / TLS，这可能会带来良好的性能优势，特别是涉及硬件PKCS＃11令牌。 HttpUrlConnection 也有一个内部池，但你没有工具可以自定义什么或何时池，没有监控设施来检查池状态。


• 功能详细记录

• 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. HttpUrlConnection also 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

请记住，还可以使用其他后端（例如非阻塞客户端）泽西岛，如果你有一个合适的 com.sun.jersey.api.client.ClientHandler 实施。

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.ClientHandler implementation.

这篇关于Jersey-client和Apache HTTP Client如何比较？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！