@U0W0JDY4C can you point me to the docs you are following? The service map keys need to be fully-qualified keywords (i.e., io.pedestal.http/routes or, if you have io.pedestal.http aliased to something like http then ::http/routes, etc…)

I’d also assoc ::http/join? false to the service map when so that you can stop the server when running from a repl

Finally, I’d not invoke expand-routes directly. That’s done for you by the io.pedestal.http/default-interceptors fn when create-server is invoked. Your routes should instead be

(def routes
   #{["/foo" :get `index :route-name :index]})

refer to https://github.com/pedestal/pedestal-docs/issues/66

I need to update the docs

> Finally, I’d not invoke expand-routes directly. good to know

:thumbsup: i was working off the http://pedastal.io/guides , but i see now that the ::http/ was missing

Just an FYI, I went back and looked at the source and you can call pass in routes expanded by expand-routes. Not sure what issue I ran into when I created that Github issue ages ago but I do still think you should let Pedestal’s internals expand routes for you unless you are explicitly not leveraging the defaults provided by io.pedestal.http/default-interceptors.

i’m still poking around the interceptor stuff, checking out content negotiation and coersion etc.. the whole thing looks like a great paradigm

Interceptors are great. The core set of interceptors provided by Pedestal is intentionally kept small. Application-specific needs can be implemented as interceptors pretty easily.