Nous mettons en œuvre un client de repos sur JRE 1.4.
semble que deux bonnes options pour un framework de repos client sont httpClient et Y a-t-il une raison d'utiliser httpClient sur le jre's httpurlconnection?
7 Réponses :
Dans mon expérience httpClient est légèrement plus facile et plus intuitive à utiliser que d'utiliser httpurlconnection, mais je pense que c'est une décision très subjective et YMMV.
J'irais avec la version JRE Juste alors j'aurais une dépendance inférieure à expédier.
Cette comparaison a l'air un peu daté
Certains d'entre nous n'ont pas le luxe d'utiliser les dernières versions de rien :-(
Le HttpurlConnection est facile à manipuler. Les implémentations de repos sont assez simples.
Bien que vous fassiez considérer l'ensemble de l'environnement sur cette mise en œuvre et vérifier ce qui fonctionnera mieux pour vous.
Le Framework de Restlet a également une API qui fonctionne à la fois côté serveur et côté client. Nous prenons en charge des connecteurs de cliente Pluggable, tirant parti de l'httpurlConnection ou du client HTTP Apache ou de notre propre client HTTP interne.
Notre classe clientResource fournit une API client HTTP de niveau supérieur, avec des fonctionnalités telles que la redirection automatique, la conversion transparente entre les objets et les représentations, la négociation de contenu et plus encore. .
meilleures salutations,
Jerome Louvel
Restlet ~ Fondateur et développeur de plomb ~ http://www.reslet.org
NOELIOS TECHNOLOGIES ~ co-fondateur ~ http://www.noelios.com
Nous sommes sur 1,4 - Le Restlet fonctionne-t-il sur 1,4?
@Marcus: Oui, j'utilise le client de Restlet en ce moment à Java 1.6 et c'est un rêve. (Nous l'avons configuré pour rester assis sur le client HTTP Apache, ce qui est beaucoup mieux que Java.net.httpurlConnection.)
Je vais vous donner une seule raison concrète de favoriser httpClient de Apache sur la mise en œuvre JDK: le Les applications doivent toujours avoir la possibilité de définir des tempêtes lors de l'appel dans d'autres systèmes (bases de données, services distants, votre propre serveur, ...).
httpurlconnection de JDK ne prend pas en charge les délais d'attente *, le httpclient de Apache.
Pas vrai! Ceci a été corrigé dans Java 1.5.
Je me suis trompé. Bon à savoir (c'est sur la classe d'urlconnection).
Bon point. Nous sommes sur 1.4 Cela semble totalement pertinent.
Je recommanderais le client HTTP de Jakarta Commons sur java.net.httpurlconnection car il est plus mature et a un Ensemble de fonctionnalités RICHER . Par exemple, vous pouvez la poser à la configuration du pool de connexion multi-threadé (voir MulthreadedhttponnectionManager < / a>), et il dispose d'un support complet pour toutes les méthodes HTTP (obtenez, mettre, poster, supprimer, options, trace).
... httpclient ne prend pas en charge l'authentification Kerberos / NTLM pour les proxies, etc. L'httpurlconnection de Java fera l'authentification hors de la boîte ...
Cette comparaison regarde en fait des innovations httpclient, il n'a rien à voir avec HttpClient Afaik d'Apache
Merci d'objets .. Lien supprimé.