§The Play WS API
Sometimes we would like to call other HTTP services from within a Play application. Play supports this via its WS library, which provides a way to make asynchronous HTTP calls.
There are two important parts to using the WS API: making a request, and processing the response. We’ll discuss how to make both GET and POST HTTP requests first, and then show how to process the response from WS. Finally, we’ll discuss some common use cases.
§Making a Request
To use WS, first add ws
to your build.sbt
file:
libraryDependencies ++= Seq(
ws
)
Then import the following:
import play.api.Play.current
import play.api.libs.ws._
import play.api.libs.ws.ning.NingAsyncHttpClientConfigBuilder
import scala.concurrent.Future
To build an HTTP request, you start with WS.url()
to specify the URL.
val holder: WSRequestHolder = WS.url(url)
This returns a WSRequestHolder that you can use to specify various HTTP options, such as setting headers. You can chain calls together to construct complex requests.
val complexHolder: WSRequestHolder =
holder.withHeaders("Accept" -> "application/json")
.withRequestTimeout(10000)
.withQueryString("search" -> "play")
You end by calling a method corresponding to the HTTP method you want to use. This ends the chain, and uses all the options defined on the built request in the WSRequestHolder
.
val futureResponse: Future[WSResponse] = complexHolder.get()
This returns a Future[WSResponse]
where the Response contains the data returned from the server.
§Request with authentication
If you need to use HTTP authentication, you can specify it in the builder, using a username, password, and an AuthScheme. Valid case objects for the AuthScheme are BASIC
, DIGEST
, KERBEROS
, NONE
, NTLM
, and SPNEGO
.
WS.url(url).withAuth(user, password, WSAuthScheme.BASIC).get()
§Request with follow redirects
If an HTTP call results in a 302 or a 301 redirect, you can automatically follow the redirect without having to make another call.
WS.url(url).withFollowRedirects(true).get()
§Request with query parameters
Parameters can be specified as a series of key/value tuples.
WS.url(url).withQueryString("paramKey" -> "paramValue").get()
§Request with additional headers
Headers can be specified as a series of key/value tuples.
WS.url(url).withHeaders("headerKey" -> "headerValue").get()
If you are sending plain text in a particular format, you may want to define the content type explicitly.
WS.url(url).withHeaders("Content-Type" -> "application/xml").post(xmlString)
§Request with virtual host
A virtual host can be specified as a string.
WS.url(url).withVirtualHost("192.168.1.1").get()
§Request with timeout
If you wish to specify a request timeout, you can use withRequestTimeout
to set a value in milliseconds.
WS.url(url).withRequestTimeout(5000).get()
§Submitting form data
To post url-form-encoded data a Map[String, Seq[String]]
needs to be passed into post
.
WS.url(url).post(Map("key" -> Seq("value")))
§Submitting JSON data
The easiest way to post JSON data is to use the JSON library.
import play.api.libs.json._
val data = Json.obj(
"key1" -> "value1",
"key2" -> "value2"
)
val futureResponse: Future[WSResponse] = WS.url(url).post(data)
§Submitting XML data
The easiest way to post XML data is to use XML literals. XML literals are convenient, but not very fast. For efficiency, consider using an XML view template, or a JAXB library.
val data = <person>
<name>Steve</name>
<age>23</age>
</person>
val futureResponse: Future[WSResponse] = WS.url(url).post(data)
§Processing the Response
Working with the Response is easily done by mapping inside the Future.
The examples given below have some common dependencies that will be shown once here for brevity.
Whenever an operation is done on a Future
, an implicit execution context must be available - this declares which thread pool the callback to the future should run in. The default Play execution context is often sufficient:
implicit val context = play.api.libs.concurrent.Execution.Implicits.defaultContext
The examples also use the folowing case class for serialization / deserialization:
case class Person(name: String, age: Int)
§Processing a response as JSON
You can process the response as a JSON object by calling response.json
.
val futureResult: Future[String] = WS.url(url).get().map {
response =>
(response.json \ "person" \ "name").as[String]
}
The JSON library has a useful feature that will map an implicit Reads[T]
directly to a class:
import play.api.libs.json._
implicit val personReads = Json.reads[Person]
val futureResult: Future[JsResult[Person]] = WS.url(url).get().map {
response => (response.json \ "person").validate[Person]
}
§Processing a response as XML
You can process the response as an XML literal by calling response.xml
.
val futureResult: Future[scala.xml.NodeSeq] = WS.url(url).get().map {
response =>
response.xml \ "message"
}
§Processing large responses
Calling get()
or post()
will cause the body of the request to be loaded into memory before the response is made available. When you are downloading with large, multi-gigabyte files, this may result in unwelcome garbage collection or even out of memory errors.
WS
lets you use the response incrementally by using an iteratee. The stream()
and getStream()
methods on WSRequestHolder
return Future[(WSResponseHeaders, Enumerator[Array[Byte]])]
. The enumerator contains the response body.
Here is a trivial example that uses an iteratee to count the number of bytes returned by the response:
import play.api.libs.iteratee._
// Make the request
val futureResponse: Future[(WSResponseHeaders, Enumerator[Array[Byte]])] =
WS.url(url).getStream()
val bytesReturned: Future[Long] = futureResponse.flatMap {
case (headers, body) =>
// Count the number of bytes returned
body |>>> Iteratee.fold(0l) { (total, bytes) =>
total + bytes.length
}
}
Of course, usually you won’t want to consume large bodies like this, the more common use case is to stream the body out to another location. For example, to stream the body to a file:
import play.api.libs.iteratee._
// Make the request
val futureResponse: Future[(WSResponseHeaders, Enumerator[Array[Byte]])] =
WS.url(url).getStream()
val downloadedFile: Future[File] = futureResponse.flatMap {
case (headers, body) =>
val outputStream = new FileOutputStream(file)
// The iteratee that writes to the output stream
val iteratee = Iteratee.foreach[Array[Byte]] { bytes =>
outputStream.write(bytes)
}
// Feed the body into the iteratee
(body |>>> iteratee).andThen {
case result =>
// Close the output stream whether there was an error or not
outputStream.close()
// Get the result or rethrow the error
result.get
}.map(_ => file)
}
Another common destination for response bodies is to stream them through to a response that this server is currently serving:
def downloadFile = Action.async {
// Make the request
WS.url(url).getStream().map {
case (response, body) =>
// Check that the response was successful
if (response.status == 200) {
// Get the content type
val contentType = response.headers.get("Content-Type").flatMap(_.headOption)
.getOrElse("application/octet-stream")
// If there's a content length, send that, otherwise return the body chunked
response.headers.get("Content-Length") match {
case Some(Seq(length)) =>
Ok.feed(body).as(contentType).withHeaders("Content-Length" -> length)
case _ =>
Ok.chunked(body).as(contentType)
}
} else {
BadGateway
}
}
}
POST
and PUT
calls require manually calling the withMethod
method, eg:
val futureResponse: Future[(WSResponseHeaders, Enumerator[Array[Byte]])] =
WS.url(url).withMethod("PUT").withBody("some body").stream()
§Common Patterns and Use Cases
§Chaining WS calls
Using for comprehensions is a good way to chain WS calls in a trusted environment. You should use for comprehensions together with Future.recover to handle possible failure.
val futureResponse: Future[WSResponse] = for {
responseOne <- WS.url(urlOne).get()
responseTwo <- WS.url(responseOne.body).get()
responseThree <- WS.url(responseTwo.body).get()
} yield responseThree
futureResponse.recover {
case e: Exception =>
val exceptionData = Map("error" -> Seq(e.getMessage))
WS.url(exceptionUrl).post(exceptionData)
}
§Using in a controller
When making a request from a controller, you can map the response to a Future[Result]
. This can be used in combination with Play’s Action.async
action builder, as described in Handling Asynchronous Results.
def wsAction = Action.async {
WS.url(url).get().map { response =>
Ok(response.body)
}
}
status(wsAction(FakeRequest())) must_== OK
§Using WSClient
WSClient is a wrapper around the underlying AsyncHttpClient. It is useful for defining multiple clients with different profiles, or using a mock.
The default client can be called from the WS singleton:
val client: WSClient = WS.client
You can define a WS client directly from code without going through WS, and use implicitly with WS.clientUrl()
. Note that you should always use NingAsyncHttpClientConfigBuilder
when configuring your client, for secure TLS configuration:
val clientConfig = new DefaultWSClientConfig()
val secureDefaults:com.ning.http.client.AsyncHttpClientConfig = new NingAsyncHttpClientConfigBuilder(clientConfig).build()
// You can directly use the builder for specific options once you have secure TLS defaults...
val builder = new com.ning.http.client.AsyncHttpClientConfig.Builder(secureDefaults)
builder.setCompressionEnabled(true)
val secureDefaultsWithSpecificOptions:com.ning.http.client.AsyncHttpClientConfig = builder.build()
implicit val implicitClient = new play.api.libs.ws.ning.NingWSClient(secureDefaultsWithSpecificOptions)
val response = WS.clientUrl(url).get()
NOTE: if you instantiate a NingWSClient object, it does not use the WS plugin system, and so will not be automatically closed in
Application.onStop
. Instead, the client must be manually shutdown usingclient.close()
when processing has completed. This will release the underlying ThreadPoolExecutor used by AsyncHttpClient. Failure to close the client may result in out of memory exceptions (especially if you are reloading an application frequently in development mode).
or directly:
val response = client.url(url).get()
Or use a magnet pattern to match up certain clients automatically:
object PairMagnet {
implicit def fromPair(pair: (WSClient, java.net.URL)) =
new WSRequestHolderMagnet {
def apply(): WSRequestHolder = {
val (client, netUrl) = pair
client.url(netUrl.toString)
}
}
}
import scala.language.implicitConversions
import PairMagnet._
val client = WS.client
val exampleURL = new java.net.URL(url)
val response = WS.url(client -> exampleURL).get()
By default, configuration happens in application.conf
, but you can also set up the builder directly from configuration:
import com.typesafe.config.ConfigFactory
import play.api.libs.ws._
import play.api.libs.ws.ning._
val configuration = play.api.Configuration(ConfigFactory.parseString(
"""
|ws.followRedirects = true
""".stripMargin))
val classLoader = app.classloader // Play.current.classloader or other
val parser = new DefaultWSConfigParser(configuration, classLoader)
val builder = new NingAsyncHttpClientConfigBuilder(parser.parse())
You can also get access to the underlying async client.
import com.ning.http.client.AsyncHttpClient
val client: AsyncHttpClient = WS.client.underlying
This is important in a couple of cases. WS has a couple of limitations that require access to the client:
WS
does not support multi part form upload directly. You can use the underlying client with RequestBuilder.addBodyPart.WS
does not support streaming body upload. In this case, you should use theFeedableBodyGenerator
provided by AsyncHttpClient.
§Configuring WS
Use the following properties in application.conf
to configure the WS client:
ws.followRedirects
: Configures the client to follow 301 and 302 redirects (default is true).ws.useProxyProperties
: To use the system http proxy settings(http.proxyHost, http.proxyPort) (default is true).ws.useragent
: To configure the User-Agent header field.ws.compressionEnabled
: Set it to true to use gzip/deflater encoding (default is false).
§Configuring WS with SSL
To configure WS for use with HTTP over SSL/TLS (HTTPS), please see Configuring WS SSL.
§Configuring Timeouts
There are 3 different timeouts in WS. Reaching a timeout causes the WS request to interrupt.
ws.timeout.connection
: The maximum time to wait when connecting to the remote host (default is 120 seconds).ws.timeout.idle
: The maximum time the request can stay idle (connection is established but waiting for more data) (default is 120 seconds).ws.timeout.request
: The total time you accept a request to take (it will be interrupted even if the remote host is still sending data) (default is none, to allow stream consuming).
The request timeout can be overridden for a specific connection with withRequestTimeout()
(see “Making a Request” section).
Next: OpenID Support in Play