=doc fix mentions of spray and link to magnet pattern
This commit is contained in:
parent
546936146b
commit
fd85cac20f
19 changed files with 27 additions and 28 deletions
|
|
@ -136,7 +136,7 @@ class HttpServerExampleSpec extends WordSpec with Matchers {
|
|||
path("hello") {
|
||||
get {
|
||||
complete {
|
||||
<h1>Say hello to spray</h1>
|
||||
<h1>Say hello to akka-http</h1>
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -28,14 +28,14 @@ class RespondWithDirectivesExamplesSpec extends RoutingSpec {
|
|||
"respondWithHeaders-examples" in {
|
||||
val route =
|
||||
path("foo") {
|
||||
respondWithHeaders(RawHeader("Funky-Muppet", "gonzo"), Origin(Seq(HttpOrigin("http://spray.io")))) {
|
||||
respondWithHeaders(RawHeader("Funky-Muppet", "gonzo"), Origin(Seq(HttpOrigin("http://akka.io")))) {
|
||||
complete("beep")
|
||||
}
|
||||
}
|
||||
|
||||
Get("/foo") ~> route ~> check {
|
||||
header("Funky-Muppet") shouldEqual Some(RawHeader("Funky-Muppet", "gonzo"))
|
||||
header[Origin] shouldEqual Some(Origin(Seq(HttpOrigin("http://spray.io"))))
|
||||
header[Origin] shouldEqual Some(Origin(Seq(HttpOrigin("http://akka.io"))))
|
||||
responseAs[String] shouldEqual "beep"
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ targeted by the request has already been established and the respective ETag/Las
|
|||
|
||||
|
||||
The :ref:`FileAndResourceDirectives` internally use the ``conditional`` directive for ETag and Last-Modified support
|
||||
(if the ``spray.routing.file-get-conditional`` setting is enabled).
|
||||
(if the ``akka.http.routing.file-get-conditional`` setting is enabled).
|
||||
|
||||
__ http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-26#section-6
|
||||
__ https://datatracker.ietf.org/wg/httpbis/
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Signature
|
|||
The signature shown is simplified, the real signature uses magnets. [1]_
|
||||
|
||||
.. [1] See `The Magnet Pattern`_ for an explanation of magnet-based overloading.
|
||||
.. _`The Magnet Pattern`: /blog/2012-12-13-the-magnet-pattern/
|
||||
.. _`The Magnet Pattern`: http://spray.io/blog/2012-12-13-the-magnet-pattern/
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Signature
|
|||
The signature shown is simplified, the real signature uses magnets. [1]_
|
||||
|
||||
.. [1] See `The Magnet Pattern`_ for an explanation of magnet-based overloading.
|
||||
.. _`The Magnet Pattern`: /blog/2012-12-13-the-magnet-pattern/
|
||||
.. _`The Magnet Pattern`: http://spray.io/blog/2012-12-13-the-magnet-pattern/
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Signature
|
|||
The signature shown is simplified, the real signature uses magnets. [1]_
|
||||
|
||||
.. [1] See `The Magnet Pattern`_ for an explanation of magnet-based overloading.
|
||||
.. _`The Magnet Pattern`: /blog/2012-12-13-the-magnet-pattern/
|
||||
.. _`The Magnet Pattern`: http://spray.io/blog/2012-12-13-the-magnet-pattern/
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
FileAndResourceDirectives
|
||||
=========================
|
||||
|
||||
Like the :ref:`RouteDirectives` the ``FileAndResourceDirectives`` are somewhat special in spray's routing DSL.
|
||||
Like the :ref:`RouteDirectives` the ``FileAndResourceDirectives`` are somewhat special in akka-http's routing DSL.
|
||||
Contrary to all other directives they do not produce instances of type ``Directive[L <: HList]`` but rather "plain"
|
||||
routes of type ``Route``.
|
||||
The reason is that they are not meant for wrapping an inner route (like most other directives, as intermediate-level
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ The signature shown is simplified and written in pseudo-syntax, the real signatu
|
|||
``<FieldDef>`` doesn't really exist but consists of the syntactic variants as shown in the description and the examples.
|
||||
|
||||
.. [1] See `The Magnet Pattern`_ for an explanation of magnet-based overloading.
|
||||
.. _`The Magnet Pattern`: /blog/2012-12-13-the-magnet-pattern/
|
||||
.. _`The Magnet Pattern`: http://spray.io/blog/2012-12-13-the-magnet-pattern/
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Signature
|
|||
The signature shown is simplified, the real signature uses magnets. [1]_
|
||||
|
||||
.. [1] See `The Magnet Pattern`_ for an explanation of magnet-based overloading.
|
||||
.. _`The Magnet Pattern`: /blog/2012-12-13-the-magnet-pattern/
|
||||
.. _`The Magnet Pattern`: http://spray.io/blog/2012-12-13-the-magnet-pattern/
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Signature
|
|||
The signature shown is simplified, the real signature uses magnets. [1]_
|
||||
|
||||
.. [1] See `The Magnet Pattern`_ for an explanation of magnet-based overloading.
|
||||
.. _`The Magnet Pattern`: /blog/2012-12-13-the-magnet-pattern/
|
||||
.. _`The Magnet Pattern`: http://spray.io/blog/2012-12-13-the-magnet-pattern/
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ entity
|
|||
Unmarshalls the request entity to the given type and passes it to its inner Route. An unmarshaller
|
||||
returns an ``Either`` with ``Right(value)`` if successful or ``Left(exception)`` for a failure.
|
||||
The ``entity`` method will either pass the ``value`` to the inner route or map the ``exception`` to a
|
||||
``spray.routing.Rejection``.
|
||||
``akka.http.scaladsl.server.Rejection``.
|
||||
|
||||
Signature
|
||||
---------
|
||||
|
|
@ -17,13 +17,13 @@ Signature
|
|||
Description
|
||||
-----------
|
||||
|
||||
The ``entity`` directive works in conjuction with ``as`` and ``spray.httpx.unmarshalling`` to
|
||||
The ``entity`` directive works in conjuction with ``as`` and ``akka.http.scaladsl.unmarshalling`` to
|
||||
convert some serialized "wire format" value into a higher-level object structure.
|
||||
:ref:`The unmarshalling documentation <http-unmarshalling-scala>` explains this process in detail.
|
||||
This directive simplifies extraction and error handling to the specified type from the request.
|
||||
|
||||
An unmarshaller will return a ``Left(exception)`` in the case of an error. This is converted to a
|
||||
``spray.routing.Rejection`` within the ``entity`` directive. The following table lists how exceptions
|
||||
``akka.http.scaladsl.server.Rejection`` within the ``entity`` directive. The following table lists how exceptions
|
||||
are mapped to rejections:
|
||||
|
||||
========================== ============
|
||||
|
|
|
|||
|
|
@ -21,15 +21,15 @@ The ``handleWith`` directive is used when you want to handle a route with a give
|
|||
type A ⇒ B. ``handleWith`` will use both an in-scope unmarshaller to convert a request into
|
||||
type A and an in-scope marshaller to convert type B into a response. This is helpful when your
|
||||
core business logic resides in some other class or you want your business logic to be independent
|
||||
of *Spray*. You can use ``handleWith`` to "hand off" processing to a given function without requiring
|
||||
any spray-specific functionality.
|
||||
of the REST interface written with akka-http. You can use ``handleWith`` to "hand off" processing
|
||||
to a given function without requiring any akka-http-specific functionality.
|
||||
|
||||
``handleWith`` is similar to ``produce``. The main difference is ``handleWith`` automatically
|
||||
calls ``complete`` when the function passed to ``handleWith`` returns. Using ``produce`` you
|
||||
must explicity call the completion function passed from the ``produce`` function.
|
||||
|
||||
See :ref:`marshalling <http-marshalling-scala>` and :ref:`unmarshalling <http-unmarshalling-scala>` for guidance
|
||||
on marshalling entities with Spray.
|
||||
on marshalling entities with akka-http.
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Marshalling Directives
|
||||
======================
|
||||
|
||||
Marshalling directives work in conjunction with ``spray.httpx.marshalling`` and ``spray.httpx.unmarshalling`` to convert
|
||||
Marshalling directives work in conjunction with ``akka.http.scaladsl.marshalling`` and ``akka.http.scaladsl.unmarshalling`` to convert
|
||||
a request entity to a specific type or a type to a response.
|
||||
|
||||
See :ref:`marshalling <http-marshalling-scala>` and :ref:`unmarshalling <http-unmarshalling-scala>` for specific
|
||||
|
|
|
|||
|
|
@ -19,8 +19,8 @@ method ``HEAD`` are passed on to the inner route. All others are rejected with a
|
|||
``MethodRejection``, which is translated into a ``405 Method Not Allowed`` response
|
||||
by the default :ref:`RejectionHandler <The RejectionHandler>`.
|
||||
|
||||
.. note:: By default, spray-can handles HEAD-requests transparently by dispatching a GET-request to the handler and
|
||||
stripping of the result body. See the ``spray.can.server.transparent-head-requests`` setting for how to disable
|
||||
.. note:: By default, akka-http handles HEAD-requests transparently by dispatching a GET-request to the handler and
|
||||
stripping of the result body. See the ``akka.http.server.transparent-head-requests`` setting for how to disable
|
||||
this behavior.
|
||||
|
||||
Example
|
||||
|
|
|
|||
|
|
@ -15,9 +15,8 @@ Signature
|
|||
Description
|
||||
-----------
|
||||
|
||||
spray-can and spray-servlet adds the ``Remote-Address`` header to every request automatically if the respective
|
||||
setting ``spray.can.server.remote-address-header`` or ``spray.servlet.remote-address-header`` is set to ``on``.
|
||||
Per default it is set to ``off``.
|
||||
The akka-http server engine adds the ``Remote-Address`` header to every request automatically if the respective
|
||||
setting ``akka.http.server.remote-address-header`` is set to ``on``. Per default it is set to ``off``.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ The signature shown is simplified and written in pseudo-syntax, the real signatu
|
|||
``<ParamDef>`` doesn't really exist but consists of the syntactic variants as shown in the description and the examples.
|
||||
|
||||
.. [1] See `The Magnet Pattern`_ for an explanation of magnet-based overloading.
|
||||
.. _`The Magnet Pattern`: /blog/2012-12-13-the-magnet-pattern/
|
||||
.. _`The Magnet Pattern`: http://spray.io/blog/2012-12-13-the-magnet-pattern/
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Signature
|
|||
The signature shown is simplified, the real signature uses magnets. [1]_
|
||||
|
||||
.. [1] See `The Magnet Pattern`_ for an explanation of magnet-based overloading.
|
||||
.. _`The Magnet Pattern`: /blog/2012-12-13-the-magnet-pattern/
|
||||
.. _`The Magnet Pattern`: http://spray.io/blog/2012-12-13-the-magnet-pattern/
|
||||
|
||||
|
||||
Description
|
||||
|
|
@ -34,7 +34,7 @@ ranges with a ``TooManyRangesRejection``.
|
|||
Requests with unsatisfiable ranges are rejected with an ``UnsatisfiableRangeRejection``.
|
||||
|
||||
The ``withRangeSupport()`` form (without parameters) uses the ``range-coalescing-threshold`` and ``range-count-limit``
|
||||
settings from the ``spray.routing`` configuration.
|
||||
settings from the ``akka.http.routing`` configuration.
|
||||
|
||||
This directive is transparent to non-``GET`` requests.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Signature
|
|||
|
||||
The signature shown is simplified, the real signature uses magnets. [1]_
|
||||
|
||||
.. [1] See `The Magnet Pattern </blog/2012-12-13-the-magnet-pattern/>`_ for an explanation of magnet-based overloading.
|
||||
.. [1] See `The Magnet Pattern <http://spray.io/blog/2012-12-13-the-magnet-pattern/>`_ for an explanation of magnet-based overloading.
|
||||
|
||||
|
||||
Description
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
RouteDirectives
|
||||
===============
|
||||
|
||||
The ``RouteDirectives`` have a special role in spray's routing DSL. Contrary to all other directives (except most
|
||||
The ``RouteDirectives`` have a special role in akka-http's routing DSL. Contrary to all other directives (except most
|
||||
:ref:`FileAndResourceDirectives`) they do not produce instances of type ``Directive[L <: HList]`` but rather "plain"
|
||||
routes of type ``Route``.
|
||||
The reason is that the ``RouteDirectives`` are not meant for wrapping an inner route (like most other directives, as
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue