web-dev-qa-db-fra.com

Comment Jersey-client et Apache HTTP Client se comparent-ils?

Tout d'abord, je n'essaie pas de déclencher une guerre des flammes ici. Je connais assez bien Jersey, mais j'ai à peine utilisé httpclient.

Quelles sont les principales différences entre jersey-client et httpclient d'Apache? Dans quels domaines l'un est-il meilleur que l'autre? Y a-t-il un bon tableau de comparaison quelque part? Lequel fonctionne mieux avec des fichiers plus volumineux (disons 2048 Mo)?

Un grand merci pour vos commentaires!

javaapache-httpclient-4.xapache-commons-httpclientjersey-client
48
carlspring

Ces deux choses ne devraient probablement pas être comparées directement. Jersey est un client REST, avec une implémentation JAX-RS complète, une API fluide et une pile de filtres puissante. Apache Http Client est un client HTTP, parfait pour gérer les détails de bas niveau comme les délais d'attente, les routes proxy complexes et l'interrogation de connexion. Ils agissent à différents niveaux de votre pile de protocoles. Lorsque vous utilisez Jersey, il y a toujours une sorte de backend client HTTP impliqué. En l'absence de backend explicite, Jersey utilisera HttpUrlConnection comme backend par défaut.

Exemple de backend Jersey avec HttpUrlConnection:

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

Exemple de backend avec Jersey Apache Http Client:

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

Veuillez noter l'utilisation de Handler dans le dernier exemple. Il s'agit d'une abstraction d'intégration clé pour Jersey afin d'incorporer et d'utiliser divers backends. Le premier exemple utilise URLConnectionClientHandler profondément sous le capot.

En parlant de performances et de fonctionnalités, il est peu logique de comparer Apache Http Client avec Jersey. On peut vouloir comparer différents backends de Jersey ici, car Jersey lui-même n'est qu'une API d'encapsulation. Je voudrais souligner certaines différences clés entre HttpUrlConnection et Apache Http Client en fonction de ma propre expérience:

HttpUrlConnection

  • Aucune dépendance externe n'est nécessaire. Cela peut être très utile sur les plates-formes embarquées ou mobiles.
  • Extrêmement bien documenté partout
  • A une API mal conçue. L'implémentation basée sur HttpUrlConnection est difficile à maintenir et à étendre.
  • De nombreuses fonctionnalités sont configurées via les propriétés JVM, dont certaines peuvent ne pas être reconfigurables pendant l'exécution.
  • Dans certains cas, désespéré pour gérer les délais d'attente. Vous pouvez finir par définir 10 propriétés JVM différentes pour différents délais d'expiration et toujours bloquer vos connexions pour toujours dans certaines circonstances.
  • Depuis Gingerbread est un recommandé API client http pour Android.

Client Apache Http

  • Pour les versions 3.X, ses performances étaient quelque peu similaires à HttpUrlConnection. La version 4.1 contient de nombreuses améliorations de performances et fonctionne bien mieux que son homologue
  • Assez bon pour gérer les délais de connexion et de lecture des données
  • Sa conception suit Open/Closed Principle , vous pouvez donc personnaliser presque n'importe quelle partie du traitement HTTP avec votre propre implémentation. Exemples: stratégies de redirection, stratégies de nouvelle tentative, stockages de cookies personnalisés, intercepteurs de demandes/réponses, etc.
  • Fournit une prise en charge de proxy riche avec des constructeurs de routes personnalisables pour les chemins multi-proxy complexes
  • A un pool de connexions par route prêt à l'emploi. Cela peut offrir un bon avantage en termes de performances si SSL/TLS est utilisé, en particulier avec des jetons PKCS # 11 matériels impliqués. HttpUrlConnection dispose également d'un pool interne, mais vous n'avez aucun outil pour personnaliser quoi ou quand mettre en pool, pas de fonctions de surveillance pour vérifier l'état du pool.
  • Caractéristiques de journalisation détaillée

Gardez à l'esprit qu'il est également possible d'utiliser d'autres backends (par exemple pour les clients non bloquants) avec Jersey si vous disposez d'un com.Sun.jersey.api.client.ClientHandler la mise en oeuvre.

78
Jk1