Jersey 客户端和 Apache HTTP 客户端如何比较? [英] 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.

Jersey 与 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 示例:

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 进行比较毫无意义.人们可能想在这里比较不同的 Jersey 后端，因为 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 实现，也可以将其他后端(例如用于非阻塞客户端)与 Jersey 一起使用.

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 客户端和 Apache HTTP 客户端如何比较?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！