wake-up-neo.com

Wie vergleichen sich Jersey-Client und Apache HTTP Client?

Zunächst versuche ich nicht, hier einen Flammenkrieg zu beginnen. Ich kenne Jersey ausreichend gut, habe aber httpclient kaum genutzt.

Was sind die Hauptunterschiede zwischen dem Jersey-Client und dem httpclient von Apache? In welchen Bereichen ist einer besser als der andere? Gibt es irgendwo eine gute Vergleichstabelle? Welche ist bei größeren Dateien (z. B. 2048 MB) besser?

Vielen Dank für Ihre Kommentare!

48
carlspring

Diese beiden Dinge sollten wahrscheinlich nicht direkt verglichen werden. Jersey ist ein REST-Client, der über eine vollständige JAX-RS-Implementierung, eine flüssige API und einen leistungsstarken Filterstack verfügt. Der Apache Http Client ist ein HTTP-Client, der sich perfekt für die Verwaltung von Details auf niedriger Ebene eignet, z. B. Zeitüberschreitungen, komplexe Proxy-Routen und Verbindungsabrufe. Sie wirken auf verschiedenen Ebenen Ihres Protokollstapels. Wenn Sie Jersey verwenden, ist immer eine Art HTTP-Client-Backend beteiligt. Wird kein Backend explizit angegeben, verwendet Jersey HttpUrlConnection als Standard-Backend.

Jersey mit HttpUrlConnection-Backend-Beispiel:

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

Jersey mit Apache Http Client Backend Beispiel:

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

Bitte beachten Sie die Verwendung von Handler im letzten Beispiel. Dies ist eine wichtige Integrationsabstraktion für Jersey, um verschiedene Backends zu integrieren und zu nutzen. Das erste Beispiel verwendet URLConnectionClientHandler tief unter der Haube.

In Bezug auf Leistung und Funktionen ist es wenig sinnvoll, Apache Http Client mit Jersey zu vergleichen. Man kann hier verschiedene Jersey-Backends vergleichen, da Jersey selbst nur eine Wrapping-API ist. Ich möchte einige wichtige Unterschiede zwischen HttpUrlConnection und Apache Http Client hervorheben, die auf meinen eigenen Erfahrungen beruhen:

HttpUrlConnection

  • Es sind keine externen Abhängigkeiten erforderlich. Dies kann auf eingebetteten oder mobilen Plattformen sehr hilfreich sein.
  • Überall sehr gut dokumentiert
  • Hat schlecht gestaltete API. HttpUrlConnection -basierte Implementierung ist schwierig zu warten und zu erweitern.
  • Viele Funktionen werden über JVM-Eigenschaften konfiguriert, von denen einige zur Laufzeit möglicherweise nicht rekonfigurierbar sind.
  • In einigen Fällen hoffnungslos bei der Behandlung von Timeouts. Sie können am Ende 10 verschiedene JVM-Eigenschaften für unterschiedliche Zeitüberschreitungen festlegen und Ihre Verbindungen unter bestimmten Umständen für immer zum Erliegen bringen.
  • Da Gingerbread eine empfohlene http-Client-API für Android ist.

Apache Http Client

  • Für 3.X-Versionen war die Leistung etwas ähnlich wie bei HttpUrlConnection. Version 4.1 enthält viele Leistungsverbesserungen und bietet eine deutlich bessere Leistung als das Gegenstück
  • Sehr gut in der Verwaltung von Zeitüberschreitungen bei Verbindungen und Datenlesevorgängen
  • Das Design folgt Open/Closed Principle , sodass Sie fast jeden Teil der HTTP-Verarbeitung mit Ihrer eigenen Implementierung anpassen können. Beispiele: Weiterleitungsstrategien, Wiederholungsstrategien, benutzerdefinierte Cookie-Speicher, Interceptors für Anforderungen/Antworten usw.
  • Bietet umfassende Proxy-Unterstützung mit anpassbaren Routenerstellungsprogrammen für komplexe Mehrfach-Proxy-Pfade
  • Hat out-of-the-Box-Verbindungspool pro Route. Dies kann bei Verwendung von SSL/TLS zu einem guten Leistungsvorteil führen, insbesondere wenn Hardware-PKCS # 11-Token beteiligt sind. HttpUrlConnection verfügt auch über ein internes Pooling, aber Sie haben keine Tools zum Anpassen, was oder wann gepoolt werden soll, keine Überwachungsfunktionen zum Überprüfen des Poolstatus.
  • Verfügt über eine detaillierte Protokollierung

Denken Sie daran, dass es auch möglich ist, andere Backends (z. B. für nicht blockierende Clients) mit Jersey zu verwenden, wenn Sie ein geeignetes com.Sun.jersey.api.client.ClientHandler Implementierung.

78
Jk1