@malcolmsparks: indeed map notation is redundant in bidi and I rarely use it, as it gives unpredictable results for matching routes (order is important in our api). That would be really cool if the 'map' form would be the integration with bidi

The use case for walking the tree is as follows: there are multiple 'apps' on the platform, and each endpoint has a route /:app-id/some/resource, now there's two things for which I'm using postwalk: 1/ all these endpoints share quite a lot in terms of parameters, produces, ... 2/ i would like to send a 404 when the :app-id doesn't exist. also, when it exists, already assoc the app retrieved from the database in the context.

the second one looks for existing :methods, and adapts the :response function to do the 404 check and inserting the app inside the ctx

not sure if that's in line with the yada idiom for modifying trees

Yes I agree. Less boilerplate and more 'dataish'. I think I'll deprecate the map syntax in bidi - I agree it causes more problems that it solves

I'm also thinking of functions e.g. 'api' that take such a tree and to the tree walk for you, calling your resource 'filters' ehich you can give it. A resource filter would update a resource (e.g. add a security model). 'Filter' in the dsp sense, not in the clojure core lib sense

I think that's a good idea. I just modified the old update-routes to

(defn update-routes [routes f & args]
  (postwalk
    (fn [x]
      (if (instance? Resource x)
        (resource (apply f x args))
        x))
    routes))