Einfache und übersichtliche HTTP-Client-Bibliothek für Scala

Ich benötige eine ausgereifte HTTP-Client-Bibliothek, die für Scala idiomatisch, präzise in der Verwendung und einfache Semantik ist. Ich habe mir das Apache HTTP und den Scala Dispatch sowie zahlreiche neue Bibliotheken angesehen, die eine idiomatische Scala-Verpackung versprechen. Der Apache HTTP-Client verlangt sicher Ausführlichkeit, während der Versand leicht verwirrend war.

Was ist ein geeigneter HTTP-Client für die Verwendung von Scala?

Ich habe kürzlich angefangen, Dispatch zu verwenden , ein bisschen arkan (großartiges allgemeines Intro, ernsthafter Mangel an detaillierten, auf Szenarien / Anwendungsfällen basierenden Dokumenten). Dispatch 0.9.1 ist ein Scala-Wrapper um Nings Async Http Client . Um vollständig zu verstehen, was vor sich geht, muss man sich in diese Bibliothek einführen. In der Praxis musste ich mir nur den RequestBuilder ansehen - alles andere passt gut zu meinem Verständnis von HTTP.

Ich gebe der Version 0.9 (bis jetzt!) Einen Daumen hoch, wenn es darum geht, die Arbeit ganz einfach zu erledigen. Sobald Sie diese anfängliche Lernkurve überwunden haben.

Der HTTP- "Builder" von Dispatch ist unveränderlich und scheint in einer Thread-Umgebung gut zu funktionieren. Obwohl ich in Dokumenten nichts finden kann, was besagt, dass es threadsicher ist; Das allgemeine Lesen der Quelle legt nahe, dass dies der Fall ist.

Beachten Sie, dass die RequestBuilder veränderbar und daher NICHT threadsicher sind.

Hier sind einige zusätzliche Links, die ich hilfreich fand:

• Ich kann keinen ScalaDoc-Link für die Version 0.9. * Finden, daher durchsuche ich den Quellcode nach der Version 0.9. * .

• ScalaDoc für die Version 0.8 ; ein wesentlich anderes Tier (heute) als 0,9.

• Das "Periodensystem" der Operatoren, ebenfalls 0,8 verwandt.

• Die älteren 0,8 "dispatch-classic" -Dokumente halfen mir zu verstehen, wie sie die URL-Builder verwendeten, und gaben einige Hinweise, wie Dinge miteinander verbunden sind, die sich auf 0,9 übertragen haben.

Ich habe einen Vergleich der meisten verfügbaren HTTP-Client-Bibliotheken durchgeführt

Der Versand und einige andere Bibliotheken werden nicht mehr verwaltet . Die einzigen ernsthaften sind derzeit Spray-Client und Play! WS .

Spray-Client ist in seiner Syntax etwas arkan. play-ws ist recht einfach zu bedienen:

(build.sbt)

libraryDependencies += "com.typesafe.play" %% "play-ws" % "2.4.3"

(Grundgebrauch)

val wsClient = NingWSClient()
wsClient
  .url("http://wwww.something.com")
  .get()
  .map { wsResponse =>
    // read the response
}

Ein bisschen spät zur Party hier, aber ich war beeindruckt von Spray-Client .

Es verfügt über ein nettes DSL zum Erstellen von Anforderungen, unterstützt sowohl die synchrone als auch die asynchrone Ausführung sowie eine Vielzahl von (un) Marshalling-Typen (JSON, XML, Formulare). Es spielt auch sehr gut mit Akka .

Zwei Sechs Jahre nachdem ich ursprünglich auf diesen Beitrag geantwortet hatte, hätte ich eine andere Antwort.

Ich habe akka-http verwendet , eine Zusammenarbeit zwischen dem Spray- und dem akka-Team. Es wird von Lightbend unterstützt und ist eng an die asynchrone Akka-Umgebung angepasst. Es ist das richtige Werkzeug für diesen Job.

Nachdem ich einige unglückliche Erfahrungen mit dem Apache-Client gemacht hatte, begann ich, meine eigenen zu schreiben. Die eingebaute HttpURLConnection wird allgemein als fehlerhaft eingestuft. Aber das ist nicht meine Erfahrung damit. In der Tat war das Gegenteil der Fall, da der Apache-Client ein etwas problematisches Threading-Modell hatte. Seit Java6 (oder 5?) Hat HttpURLConnection effiziente HTTP1.1-Verbindungen bereitgestellt, bei denen wichtige Funktionen wie Keep-Alive integriert sind, und die gleichzeitige Verwendung ist unkompliziert.

Um die unbequeme API von HttpURLConnection zu kompensieren, habe ich mich daran gemacht, eine neue API in Scala als Open-Source-Projekt zu schreiben. Es ist nur ein Wrapper für HttpURLConnection, aber im Gegensatz zu HttpURLConnection soll es einfach zu bedienen sein. Im Gegensatz zum Apache-Client sollte es problemlos in ein vorhandenes Projekt passen. Im Gegensatz zum Versand sollte es leicht zu erlernen sein.

Es heißt Bee Client

• Website: http://www.bigbeeconsultants.co.uk/bee-client
• API-Dokumente: http://www.bigbeeconsultants.co.uk/docs/bee-client/latest.html

Ich entschuldige mich für den schamlosen Stecker. :) :)

sttp ist die Scala HTTP-Bibliothek, auf die wir alle gewartet haben!

Es verfügt über ein fließendes DSL zum Bilden und Ausführen von Anforderungen (Codebeispiele aus der README-Datei):

val request = sttp
  .cookie("session", "*!@#!@!$")
  .body(file) // of type java.io.File
  .put(uri"http://httpbin.org/put")
  .auth.basic("me", "1234")
  .header("Custom-Header", "Custom-Value")
  .response(asByteArray)

Es unterstützt synchrone, asynchrone und Streaming-Anrufe über steckbare Backends, einschließlich Akka-HTTP (ehemals Spray) und des ehrwürdigen AsyncHttpClient (Netty):

implicit val sttpHandler = AsyncHttpClientFutureHandler()
val futureFirstResponse: Future[Response[String]] = request.send()

Es unterstützt scala.concurrent.Future, scalaz.concurrent.Task, monix.eval.Task, und cats.effect.IO- alle wichtigen Scala IO Monade Bibliotheken.

Außerdem hat es ein paar zusätzliche Tricks im Ärmel:

• Es enthält Fallklassendarstellungen sowohl für Anfragen als auch für Antworten (obwohl es nicht so weit geht, z. B. stark typisierte Header zu haben): https://github.com/softwaremill/sttp/blob/master/core/src/main/scala /com/softwaremill/sttp/RequestT.scala https://github.com/softwaremill/sttp/blob/master/core/src/main/scala/com/softwaremill/sttp/Response.scala

• Es bietet einen URI-String-Interpolator :

val test = "chrabąszcz majowy" val testUri: Uri = uri"http://httpbin.org/get?bug=$test"

• Es unterstützt Encoder / Decoder für Anforderungskörper / Antworten, z. B. JSON über Circe:

import com.softwaremill.sttp.circe._ val response: Either[io.circe.Error, Response] = sttp .post(uri"...") .body(requestPayload) .response(asJson[Response]) .send()

Schließlich wird es von den zuverlässigen Mitarbeitern von softwaremill gepflegt und verfügt über eine hervorragende Dokumentation .

Außer Versand gibt es da draußen nicht viel. Scalaz hatte den Versuch, einen funktionierenden http-Client zu erstellen . Aber es ist für eine Weile veraltet, es gibt keine Version davon im scalaz7-Zweig. Zusätzlich gibt es einen nützlichen Wrapper des ning async-http-clients im playframework. Dort können Sie Anrufe tätigen wie:

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

Sie können diese API als Inspiration verwenden, wenn Sie kein Spiel verwenden! in Ihrem Projekt und die Dispatch-API nicht mögen.

Sprühen

Sie sollten wirklich in Betracht ziehen, Spray zu verwenden . Meiner Meinung nach hat es eine etwas knifflige Syntax, aber es ist immer noch ziemlich brauchbar, wenn Sie einen leistungsstarken http-Client erstellen möchten. Der Hauptvorteil von Spray besteht darin, dass es auf der akka - Akteursbibliothek basiert , die extrem skalierbar und leistungsstark ist. Sie können Ihren http-Client auf mehrere Computer skalieren, indem Sie nur confDateien ändern .

Darüber hinaus ist Spray vor einigen Monaten Typesafe beigetreten, und soweit ich weiß, wird es Teil der grundlegenden Akka-Distribution. Beweis

Play2

Eine weitere Option ist die Verwendung der Play2 WS-Bibliothek ( doc ). Soweit ich weiß, ist es immer noch nicht von der Play-Distribution getrennt, aber aufgrund seiner extrem einfachen Einfachheit lohnt es sich, einige Zeit damit zu verbringen, das gesamte Play-Framework anzuhängen, um diesen Teil zu erhalten. Es gibt einige Probleme bei der Bereitstellung der Konfiguration, daher eignet sich dies nicht für Drop-and-Use-Fälle. Wir haben es jedoch in einigen nicht auf Play basierenden Projekten verwendet und alles war in Ordnung.

ScalaJ-Http ist ein sehr einfacher synchroner http-Client

https://github.com/scalaj/scalaj-http

Ich würde es empfehlen, wenn Sie einen Scala-Client ohne Zeremonie benötigen.

Überrascht, dass hier niemand Finagle erwähnte. Es ist super einfach zu bedienen:

import com.twitter.finagle.{Http, Service}
import com.twitter.finagle.http
import com.twitter.util.{Await, Future}

object Client extends App {
  val client: Service[http.Request, http.Response] = Http.newService("www.scala-lang.org:80")
  val request = http.Request(http.Method.Get, "/")
  request.host = "www.scala-lang.org"
  val response: Future[http.Response] = client(request)
  Await.result(response.onSuccess { rep: http.Response =>
    println("GET success: " + rep)
  })
}

Weitere Informationen finden Sie in der Kurzanleitung: https://twitter.github.io/finagle/guide/Quickstart.html

Ich habe Dispatch, Spray Client und die Play WS Client Library verwendet ... Keiner von ihnen war einfach zu verwenden oder zu konfigurieren. Deshalb habe ich eine einfachere HTTP-Client-Bibliothek erstellt, mit der Sie alle klassischen HTTP-Anforderungen in einfachen Einzeilern ausführen können.

Siehe ein Beispiel:

import cirrus.clients.BasicHTTP.GET

import scala.concurrent.Await
import scala.concurrent.duration._

object MinimalExample extends App {

  val html = Await.result(Cirrus(GET("https://www.google.co.uk")), 3 seconds)

  println(html)
}

... produziert ...

<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="en-GB">...</html>

Die Bibliothek heißt Cirrus und ist über Maven Central erhältlich

libraryDependencies += "com.github.godis" % "cirrus_2.11" % "1.4.1"

Die Dokumentation ist auf GitHub verfügbar

https://github.com/Godis/Cirrus