Added guides subdirectory to links.

guides/documentation/hello-world-service.md

@@ -206,6 +206,6 @@ nil
 ## Where To Go Next
 
 For more about building out the server side, you can look at
-[Routing and Linking](/documentation/service-routing.md) or
-[Connecting to Datomic](/documentation/connecting-to-datomic.md).
+[Routing and Linking](/guides/documentation/service-routing.md) or
+[Connecting to Datomic](/guides/documentation/connecting-to-datomic.md).
 

guides/documentation/service-async.md

@@ -104,6 +104,6 @@ Pedestal's built in support for server-sent events works.
 _io.pedestal.impl.inteceptor_ namespace. The code in this
 namespace is subject to change.)
 
-For more about streaming, see [Streaming Responses](/documentation/service-streaming.md). For more
-about SSE, see [Server-Sent Events](/documentation/service-sse.md).
+For more about streaming, see [Streaming Responses](//guidesdocumentation/service-streaming.md). For more
+about SSE, see [Server-Sent Events](/guides/documentation/service-sse.md).
 

guides/documentation/service-interceptors.md

@@ -88,7 +88,7 @@ Interceptors aim to explicitly solve the issue of request processing
 being coupled tightly to one thread. It does this with two mechanisms:
 
 1. Interceptors operate on a
-    [context](/documentation/service-context-reference.md) which
+    [context](/guides/documentation/service-context-reference.md) which
     explicitly retains all data associated with processing one
     request.
 
@@ -306,7 +306,7 @@ You can port Ring code to Pedestal by:
 
 - If you are using Compojure for routing requests, rewrite your route
   definitions using the terse routing format (see
-  [Service Routing](/documentation/service-routing.md)). Any Ring middlewares that run
+  [Service Routing](/guides/documentation/service-routing.md)). Any Ring middlewares that run
   before your Compojure routes should be replaced by interceptors that
   run before routing. Any middlewares specified in your Compojure
   routes should be replaced by interceptors referenced directly in

guides/documentation/service-sse.md

@@ -36,7 +36,7 @@ requests to an interceptor returned from the
 _io.pedestal.http.sse/start-event-stream_ function. The
 resulting SSE interceptor processes a request by:
 
-- pausing interceptor execution (see [Service Async](/documentation/service-async.md))
+- pausing interceptor execution (see [Service Async](/guides/documentation/service-async.md))
 
 - sending the appropriate HTTP response headers to tell the client that
   an event stream is starting.
@@ -108,7 +108,7 @@ send.
 
 It is important to understand that the server-sent events
 infrastructure uses the low-level streaming mechanism described
-[here](/documentation/service-streaming.md). As such, it is subject to the major
+[here](/guides/documentation/service-streaming.md). As such, it is subject to the major
 limitation of that approach: once events have been streamed, any
 interceptors that post-process the response from the SSE interceptor
 will not be able change what was sent on the wire. Interceptor paths

guides/documentation/service-streaming.md

@@ -55,7 +55,7 @@ The thread completing the interceptor path will write the body out to
 the HTTP response stream. If the request is processed synchronously,
 the work will be done on the Web server thread. If the request is
 processed asynchronously, the work will be done on whatever thread
-resumed processing (see [Service Async](/documentation/service-async.md)).
+resumed processing (see [Service Async](/guides/documentation/service-async.md)).
 
 Here is an example of an interceptor that returns an arbitrarily large
 volume of data.
@@ -111,5 +111,5 @@ determine whether a response has already been sent by an SSE (or
 equivalent) interceptor.
 
 This functionality is used to implement Server-Sent Events,
-documented [here](/documentation/service-sse.md).
+documented [here](/guides/documentation/service-sse.md).