anchor.diff:  
   ==== Reading the request
   
  -As we mentioned previously, the request can also be retrieved from the context instance.
  -But in our case, _catacumba_ provides helpers functions to access the most essential data
  -such as the request body, request headers, cookies and routing tokens.
  -
  -You can access to the request object using the `get-request` function. But, in almost all
  -situations you do not need it because the _catacumba_ api is polymorphic and you can get
  -access to almost all basic properties from request using a context as parameter, so you
  -don't need to extract the request from context repeatedly.
  -
  +As we mentioned previously, the `context` is the central part of the IO operations, so
  +you can treat it as request and response in the same time.
  +
  +A context behaves identical to the clojure map and contains the basic request related
  +attributes such as `:body`, `:query` and `:headers`, among others (explained in other
  +sections).
   
   ===== Body
   
  -For access to the request body, _catacumba_ exposes a `get-body` function. This function
  -returns a ratpack link:http://ratpack.io/manual/current/api/ratpack/http/TypedData.html[internal type]
  -that represents a body.
  +The request body can retrieved with the `:body` keyword from the `context`.
  +
  +[source, clojure]
  +----
  +(:body request)
  +;; => <TypedData>
  +----
  +
  +The `TypedData` is a ratpack link:http://ratpack.io/manual/current/api/ratpack/http/TypedData.html[internal type]
  +that represents the http request body.
   
   That object exposes through Java interop methods to access the content type and the raw
  -data of the request body. For convenience sake, it also implements the necesarry protocols
  -of the `clojure.java.io` namespace to make it compatible with Clojure's native facilities
  -for reading data.
  +data of the request body. For convenience, it implements the `clojure.java.io` protocols
  +for make it compatible with Clojure's native facilities for reading data.
   
   A good demostration of this is using the clojure `slurp` function. It uses
   `clojure.java.io` abstractions behind the scenes and serves as helper for reading a
  
positive.code:   drawbacks, it is build as ring adapter having all the good and all the bad of ring and
    it is using Jetty (Jetty is a servlet server that comes with optional async support, it
    isn't asynchronous from the ground up).
  
  
  === Goals
  
  Here a incomplete list of things that _catacumba_ aims to achieve:
  
  * Have a flexible and extensible way to setup different kind of handlers
  * Provide a simple and lightweight approach for defining asynchronous web services with
    support for different abstractions, such as promises, futures, core.async, manifold,
    reactive-streams, ...
  * Build almost everything up on abstractions for simple and easy extensibility.
  * Provide a built-in, data-based routing.
  * To be flexible and not very opinionated.
  * Have backpressure support out of the box.
  
  _Catacumba_ goals are not:
  
  * To be a fully integrated full stack solution like immutant or pedestal.
  * To provide an opinionated way to structure your "bussines logic"
  * To provide all possible features that you might need.
  * To be a low level, ring based library.
  
  
  === Project Maturity
  
negative.code: ----
  (def myechohandler
    [context]
    (let [^String body (slurp (:body context))]
      (http/ok body)))
  ----
  
  The `slurp` function uses the abstractions defined on the `clojure.java.io` namespace
  for read the content of the provided resourse as string and return it.
  
  Furthermore, _catacumba_ offers a more flexible way to parsing body data based on the
  incoming content type, but it is explained with more details in the
  