Hi, beginner here 🙂 How do you organize your namespaces when defining a ring router? Do you have a different cohesive namespaces for handlers and then require all in one place to setup the router? For example: (ns book-store.books) books-handler-1 books-handler-2 (ns book-store.users) users-handler-1 users-handler-2 (ns book-store.router (:require [book-store.books :refer [books-handler-1 books-handler-2]] [book-store.users :refer [users-handler-1 users-handler-2]])) (def routes ["/users" {:get users-handler-1} ...)

depends. for larger projects i prefer to split up my routes into routes.books routes.users and then merge them in a routes.core

for smaller projects it's not worth the effort splitting up the namespace so i just have a routes and all the routes in one place

@ianbishop you could do that with middleware chain transformer (https://cljdoc.org/d/metosin/reitit/0.3.10/doc/ring/transforming-middleware-chain): each chain is transformed per endpoint, so decorating an endpoint with something like :without-middleware [::some-mw], the chain transformer fn could remove the mw based on that.

If that's your own mw, it can read the endpoint data in it's :compile and not mount if there is some route data present

third option is to use meta-merge hints to override the whole chain with a new one, e.g. :middleware ^:replace []

Right on, using a transform makes sense. I wasn't sure if it would be evaluated for each chain but I guess it would need to be. I did originally try the meta-merge hint but it didn't feel great re-defing all the middleware, haha. Thanks a lot for the suggestions. I think I might go with restructuring our app a bit so there is finer control over middleware but I imagine I will end up implementing :without-middleware eventually.

I think the chain transformations could have more batteries. There is a reitit.dependency ns, which allows the chain to be re-ordered automatically based on mw/interceptor data. It could have a extra layer which would allow auto-adding required mw/int too. For users, quite far in the land of magic, but, then again, all optional.

Anyone have an example of spec’ing a Bearer Token authorization header via request coercion :parameters {:headers ...} ?

This might actually be just fine:

:parameters {:header {:authorization ::bearer-token}}

(s/def ::bearer-token
  (s/and string?
         #(let [[bearer token] (str/split % #"\s+")]
            (and (= "Bearer" bearer) (some? token)))))

Is it possible to use coercion to validate response headers?