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

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

Jersey avec exemple de backend HttpUrlConnection:

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

Exemple Jersey avec 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. Ceci est une abstraction d’intégration clé pour Jersey à intégrer et utiliser différents backends. Le premier exemple utilise URLConnectionClientHandler profondément sous le capot.

En parlant de performance et de fonctionnalités, il est inutile de comparer Apache Http Client avec Jersey. On peut vouloir comparer différents backends de Jersey ici, puisque Jersey elle-même est simplement une API enveloppante. J’aimerais mettre en évidence 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. HttpUrlConnection basée sur HttpUrlConnection est difficile à maintenir et à étendre.
• De nombreuses fonctionnalités sont configurées via des propriétés JVM, dont certaines peuvent ne pas être reconfigurables pendant l’exécution.
• Dans certains cas, sans espoir lors de la gestion des délais d’attente. Vous pouvez finir par définir 10 propriétés JVM différentes pour des délais d’attente différents et toujours suspendre vos connexions pour toujours dans certaines circonstances.
• Depuis Gingerbread est une API client http recommandée pour Android.

Apache Http Client

• Pour les versions 3.X, ses performances étaient quelque peu similaires à celles de 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 le principe Open / Closed , 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 générateurs de route personnalisables pour les chemins multy-proxy complexes
• Le pool de connexions par route est hors de la boîte. Cela peut offrir un bon avantage en termes de performances si SSL / TLS est utilisé, en particulier si des jetons PKCS # 11 sont impliqués. HttpUrlConnection également un pooling interne, mais vous ne disposez d’aucun outil pour personnaliser quoi ou quand mettre en pool, pas d’installations de contrôle pour vérifier l’état du pool.
• Comporte une journalisation détaillée

Gardez à l’esprit qu’il est également possible d’utiliser d’autres backends (par exemple pour des clients non bloquants) avec Jersey si vous avez une implémentation com.sun.jersey.api.client.ClientHandler appropriée.