what would you like to see in the Compojure-api roadmap? we will release 1.0.0 soon, can do breaking changes (for the better).

It was fairly painless to upgrade to 0.24.1, at the moment I dont have any big pain problems. It would be nice to hear a bit about what you would like to implement

https://github.com/metosin/compojure-api/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0.0

https://github.com/metosin/compojure-api/blob/runtime-route-resolution/CHANGELOG.md#100-snapshot

That's the plan and already implemented changes

Will do a good migration guide.

Should buddy be integrated in? Many have asked that and there are codes for it, one can guard the routes with :roles #{:admin}.

would make the lib much fatter, but I think most people use buddy anyway and would making the simplest possible secure api-app trivial.

Its kind is it a lib or a framework question. I rather prefer to keep the dependencies small but add good support for addons. like buddy or friend. But then again security should be a first class citizen and not as an after though.

I don't think integration is required, we could provide a better documentation or maybe even a namespace for buddy but without transitive dependency on buddy

Complete integration, like automatically adding middlewares, would need MUCH special cases like storing sessions on different databases etc.

Also, with api it will be easier to wrap the compojure-api handler in middlewares than with defapi

Now one needs to create a var with defapi and wrap that with middlewares but with api only one var is needed

(defapi app' {...} (GET* ...))
(def app  (-> app' (wrap-session) (wrap-buddy)))
=>
(def app (-> (api {...} (GET ...)) (wrap-session) (wrap-buddy)))

With the current impl. and our own macro atop of it. we fairly easy hits the method body is to large

And then the api brings in the compojure/ring-swagger middleware ?

Yeah. The same as defapi currently.

api will be a function in 1.0.0, taking options map & handler. one can compose options.

if there would be a :middlewares key in the options, one could just merge in the needed buddy-stuff. (api (merge buddy/api-options my-options) (context “/api” [] …))

but then again, @juhoteperi ’s mw-threading is as simple.

2 examples with my rest-api imp https://gist.github.com/zamaterian/53cc25e71d5104515e76

cool. with the new Routing-protocol, routing is separated from endpoints, which allows 3rd party endpoints publishing their api-docs easily. Will try to cook a Liberator-bridge later. Will ping you before starting on that.

sounds great if you want to see our impl. just say.

One thing I'd like in compojure-api would be for my custom exception handler for schema errors to be able to access the request body, so I can log the incorrect input

Specifically here: https://github.com/metosin/compojure-api/blob/master/src/compojure/api/meta.clj#L91

Not really a breaking change though. I'll file a ticket for it

The other thing that would be nice would be if route-specific middleware had access to rebound vars, I use (context* "/:id") [] :path-params id ...) blocks quite a bit in my routes, and most of the things I'd want to use route-specific middleware for aren't very useful if they can't get the id out of the route

...unless I manually parse it out of the response in the middleware, which I'm not anxious to do

@timgilbert exception handlers already can accesss req and check #198 for logging changes

Thanks @juhoteperi, will take a look