Important Protocols

IntoInterceptor allows pretty much anything to become an interceptor when needed.

Routers use this when building routes: anything that satisfies IntoInterceptor is legal to use in the interceptor vector of a route.

This protocol also comes into play when appending new interceptors to the queue.

Pedestal extends IntoInterceptor onto a variety of Clojure and Java types. See the interceptors reference for details of their behaviors.

ExpandableRoutes can convert all kinds of data structures representing a set of routes into a single canonical format that can be used to construct a routing function. This expansion occurs inside the expand-routes function.

Pedestal provides implementations of ExpandableRoutes for several types:

Likewise, each of the underlying routing specification functions (such as table-routes) returns an ExpandableRoutes.

Since the call to expand-routes comes from application code, it would be rare for an application to need to extend ExpandableRoutes.

The result of expand-routes is a wrapper around a seq of maps that will be passed to the routing contructor function.

This protocol applies to anything that can be in the :body key of a response map. The two functions in the protocol tell Pedestal what content type the body implies, and how to serialize the body to an output stream.

Pedestal extends this protocol to several Java and Clojure types to produce the behavior detailed in Response Bodies.

Applications should not assume any output stream type more specific than java.io.OutputStream.

This protocol is a more specific version of WritableBody. If the value in the :body key of a response map satisfies WritableBodyAsync, then Pedestal treats it as a streaming result. See Streaming Responses for full details.

It would be rare for an application to extend this protocol. Most of the time, an application would be better off providing an NIO channel or a core.async channel in the response body.