Bibliothèque client HTTP simple et concise pour Scala

Question

J'ai besoin d'une bibliothèque client HTTP mature qui soit idiomatique à scala, concise dans son utilisation, avec une sémantique simple. J'ai examiné Apache HTTP et Scala Dispatch ainsi que de nombreuses nouvelles bibliothèques qui promettent une enveloppe idiomatique en Scala. Le client Apache HTTP demande certainement de la verbosité, tandis que Dispatch était facilement déroutant.

Quel est un client HTTP approprié pour l'utilisation de Scala ?

Answer 1

J'ai récemment commencé à utiliser Dispatch Le système de gestion de l'information (SGI), un peu obscur (excellente introduction générale, manque sérieux de documents détaillés basés sur des scénarios ou des cas d'utilisation). Dispatch 0.9.1 est un wrapper Scala autour de l'interface de Ning Client Http asynchrone ; pour bien comprendre ce qui se passe, il faut s'introduire dans cette bibliothèque. En pratique, la seule chose que j'ai vraiment eu à regarder était la bibliothèque RequestBuilder - tout le reste correspond à ma compréhension de HTTP.

Je donne à la version 0.9 un solide coup de pouce (jusqu'à présent !) pour faire le travail très simplement une fois que vous avez passé la courbe d'apprentissage initiale.

Le "constructeur" Http de Dispatch est immuable, et semble bien fonctionner dans un environnement threadé. Bien que je ne trouve rien dans la documentation qui indique qu'il est thread-safe, la lecture générale des sources suggère qu'il l'est.

Sachez que le RequestBuilder sont mutables, et ne sont donc PAS à l'abri d'un thread.

Voici quelques liens supplémentaires que j'ai trouvés utiles :

• Je n'ai pas trouvé de lien vers ScalaDoc pour la version 0.9.*, alors j'ai parcouru le site de la code source de la version 0.9.*. ;

• ScalaDoc pour la version 0.8 ; a substantiellement bête différente (aujourd'hui) que 0.9.

• Le tableau "périodique des opérateurs, également 0,8 lié.

• Les plus âgés 0.8 Docs "dispatch-classic" (en anglais) m'a aidé à comprendre comment ils utilisaient les constructeurs d'url, et a donné quelques indications sur la façon dont les choses sont liées entre elles qui ont été reportées à la 0.9.

Answer 2

Je suis un peu en retard sur la fête ici, mais j'ai été impressionné par spray-client .

Il dispose d'un beau DSL pour construire des requêtes, supporte à la fois l'exécution sync et async, ainsi qu'une variété de types de (dé)marshalling (JSON, XML, formulaires). Il joue très bien avec Akka aussi.

Answer 3

Ayant eu quelques expériences malheureuses avec le client Apache, j'ai entrepris d'écrire le mien. La connexion HttpURLConnection intégrée est largement considérée comme boguée. Mais ce n'est pas le cas pour moi. En fait, c'est plutôt l'inverse qui s'est produit, le client Apache ayant un modèle de threading quelque peu problématique. Depuis Java6 (ou 5 ?), HttpURLConnection fournit des connexions HTTP1.1 efficaces avec des éléments essentiels comme le keep-alive intégré, et il gère l'utilisation simultanée sans problème.

Ainsi, pour compenser les inconvénients de l'API offerte par HttpURLConnection, j'ai entrepris d'écrire une nouvelle API en Scala, sous la forme d'un projet open-source. Il s'agit simplement d'une enveloppe pour HttpURLConnection, mais contrairement à HttpURLConnection, elle vise à être facile à utiliser. Contrairement au client Apache, il doit s'intégrer facilement dans un projet existant. Contrairement à Dispatch, il doit être facile à apprendre.

Il s'appelle Bee Client

• Site web : http://www.bigbeeconsultants.co.uk/bee-client
• Documentation de l'API : http://www.bigbeeconsultants.co.uk/docs/bee-client/latest.html

Toutes mes excuses pour cette publicité éhontée :)

Answer 4

A part le Dispatch, il n'y a pas grand chose. scalaz j'ai essayé de construire un client http fonctionnel. Mais il est périmé depuis un certain temps et aucune version n'existe dans la branche scalaz7. De plus, il existe un outil utile emballage de l'async-http-client de ning au sein du playframework. Là, vous pouvez faire des appels comme :

WS.url("http://example.com/feed").get()
WS.url("http://example.com/item").post("content")

Vous pouvez utiliser cette API comme source d'inspiration si vous n'utilisez pas play ! dans votre projet et si vous n'aimez pas l'API Dispatch.

Answer 5

Spray

Vous devriez vraiment envisager d'utiliser Spray . A mon avis, il a une syntaxe un peu délicate, mais il est encore assez utilisable si vous cherchez à construire un client http performant. Le principal avantage d'utiliser Spray est qu'il est basé sur la technologie akka qui est extrêmement évolutive et puissante. Vous pouvez faire évoluer votre client http vers plusieurs machines en modifiant seulement conf des fichiers.

De plus, il y a quelques mois, Spray a rejoint Typesafe, et d'après ce que j'ai compris, il fera partie de la distribution akka de base. preuve

Play2

Une autre option est l'utilisation de la librairie Play2 WS ( doc ). Pour autant que je sache, il n'est toujours pas séparé de la distribution Play, mais en raison de son extrême simplicité, il vaut la peine de passer un peu de temps à attacher l'ensemble du framework Play pour obtenir cette partie. Il y a quelques problèmes pour lui fournir une configuration, donc ce n'est pas idéal pour les cas de "drop-and-use". Cependant, nous l'avons utilisé dans quelques projets non basés sur Play et tout s'est bien passé.