aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorSam Guymer <sam@guymer.me>2018-05-20 21:02:37 +1000
committerSam Guymer <sam@guymer.me>2018-05-20 21:02:37 +1000
commitbcb94e252a96c78b1db29aebe47b18bfd337e764 (patch)
tree7462765d4dfcb2eda9a21591aba1bcfc51352b9f /docs
parent92e10991df0d168d1972d4618fcc7e02e2e0a0fa (diff)
downloadsttp-bcb94e252a96c78b1db29aebe47b18bfd337e764.tar.gz
sttp-bcb94e252a96c78b1db29aebe47b18bfd337e764.tar.bz2
sttp-bcb94e252a96c78b1db29aebe47b18bfd337e764.zip
Code review updates
Remove tests sub project, all tests are now in core. Remove TestStreamingBackend, StreamingTest now has the required abstract methods.
Diffstat (limited to 'docs')
-rw-r--r--docs/backends/custom.rst29
1 files changed, 26 insertions, 3 deletions
diff --git a/docs/backends/custom.rst b/docs/backends/custom.rst
index 17571e1..86bfb9d 100644
--- a/docs/backends/custom.rst
+++ b/docs/backends/custom.rst
@@ -3,10 +3,10 @@
Custom backends, logging, metrics
=================================
-It is also entirely possible to write custom backends (if doing so, please consider contributing!) or wrap an existing one. One can even write completely generic wrappers for any delegate backend, as each backend comes equipped with a monad for the response type. This brings the possibility to ``map`` and ``flatMap`` over responses.
+It is also entirely possible to write custom backends (if doing so, please consider contributing!) or wrap an existing one. One can even write completely generic wrappers for any delegate backend, as each backend comes equipped with a monad for the response type. This brings the possibility to ``map`` and ``flatMap`` over responses.
Possible use-cases for wrapper-backend include:
-
+
* logging
* capturing metrics
* request signing (transforming the request before sending it to the delegate)
@@ -60,7 +60,7 @@ Below is an example on how to implement a backend wrapper, which sends metrics f
class MetricWrapper[S](delegate: SttpBackend[Future, S],
metrics: MetricsServer)
extends SttpBackend[Future, S] {
-
+
override def send[T](request: Request[T, S]): Future[Response[T]] = {
val start = System.currentTimeMillis()
@@ -138,3 +138,26 @@ In some cases it's possible to implement a generic retry mechanism; such a mecha
}
Note that some backends also have built-in retry mechanisms, e.g. `akka-http <https://doc.akka.io/docs/akka-http/current/scala/http/client-side/host-level.html#retrying-a-request>`_ or `OkHttp <http://square.github.io/okhttp>`_ (see the builder's ``retryOnConnectionFailure`` method).
+
+Example new backend
+--------------------------------
+
+Implementing a new backend is made easy as the tests are published in the ``core`` jar file under the ``tests`` classifier. Simply add the follow dependencies to your ``build.sbt``::
+
+ "com.softwaremill.sttp" %% "core" % sttpVersion % "test" classifier "tests",
+ "com.github.pathikrit" %% "better-files" % "3.4.0" % "test",
+ "org.scalatest" %% "scalatest" % "3.0.5" % "test"
+
+Implement your backend and extend the ``HttpTest`` class::
+
+ import com.softwaremill.sttp.SttpBackend
+ import com.softwaremill.sttp.testing.{ConvertToFuture, HttpTest}
+
+ class MyCustomBackendHttpTest extends HttpTest[Future] {
+
+ override implicit val convertToFuture: ConvertToFuture[Future] = ConvertToFuture.future
+ override implicit lazy val backend: SttpBackend[Future, Nothing] = new MyCustomBackend()
+
+ }
+
+You can find a more detailed example in the `sttp-vertx <https://github.com/guymers/sttp-vertx>`_ repository.