@metametadata hmm.. there is a test for just that and it passes. please check out: https://github.com/metosin/compojure-api/blob/master/test/compojure/api/integration_test.clj#L494-L511. The select-formats sets the first one as default for Muuntaja.

@ikitommi thank you for a quick response! I'll look into it.

I also suspect that what I'm trying to do is not how it's expected to be done: I have a top level (api {:swagger ...}) and "leaf" apis defined in separate folders so in the end the whole "tree" looks like this:

(c/api
  {:swagger,,,}                                             ; <-----
  (c/context "/api" []
    ; first leaf
    (c/api
      {:formats leaf1-formats}                              ; <-----
      (c/context "/foo" []
        (c/GET "/bar" [],,,)
        (c/POST "/baz" [],,,)
        ))

    ; second leaf
    (c/api
      {:formats leaf2-formats}                              ; <-----
      (c/context "/baz" []
        (c/GET "/whatever" [],,,)
        ))))

Hi, I managed to make custom exception handler like this: {:exceptions {:handlers {:compojure.api.exception/default custom-handler}}

It works if there is internal error in my code, like no connection to db etc. but if user inputs something erraneous, the custom exception handler is never used, but compojure-api produces the error

hi @leena, there are two special keys for request & response errors, see details here: https://github.com/metosin/compojure-api/wiki/Exception-handling

Thanks @ikitommi !

What about if I want to return different error codes from different endpoints? Say I have some specific endpoint that I want to return 401 or 403 in certain error cases?

@leena each endpoint can declare (examples here: https://github.com/metosin/compojure-api/blob/c2274ee56334f9bfae05d69c4311cb95d18626fc/test/compojure/api/integration_test.clj#L252-L336) what kind of responses it’s returning - used for schema coercion & api-docs. But you have to create the responses yourself - c-api just makes sure you got it right. If you want to catch exceptions differently per route, you could write yourself a own middleware and attach it to endpoints or contexts via :middleware. Hope this helps

@metametadata I guess we haven’t use such combo (apis under apis), but as api is just a Route (with a bunch of middleware), I should work. Still, the options are passed top-down. In your example, the top-most api uses Muuntaja with default and that’s what the swagger-docs sees under it.

Just handle the exceptions per endpoint, or with separate middleware, if you need different error handling per route

if you want one set of api-docs but with different documentation for different endpoints, you can set the :produces or :consumes. They just contribute to docs.

(context “/only-edn-in-the-docs-context” []
  :produces [”application/edn”]
  :consumes [”application/edn”]
  …)

@ikitommi thanks, didn't know about this feature, I'll try it 🙂

yes, it does the trick and I think it's the best solution so far for me

I’ve had some success with using compojure.api.resource for building some data-driven resources, but suddenly in my tests the handlers are no longer being called and I don’t know why… The only difference I can see so far (and am pretty clueless as to why) is that the :handler I pass to compojure.api.resource/resource is an #object[] in the tests, but a #function[] at runtime (using simple pprint)

had a look at the tests in compojure-api for resource and there is no magic happening

@kennethkalmer what version are you using?

1.1.10

it does the same 1.2.0-alpha2 (but let just confirm that)

yep, same thing

expecting:

:handler
  #function[voltage.schema.resources/expand-option/handler--81507],

:handler
 #object[voltage.schema.resources$expand_option$handler__34031 0x4e1f0fdf “vo[email protected]”],

I’m stumped, I have no idea what to even start looking at

there was a routing bug with resources in pre 1.2.0, but hmm... could you isolate a non-working setup, I try to figure out whats happening

I saw the routing issue, will wait for 1.2.0 to land to update our routes, in the meantime let me check against the examples to see if it is the same

in the resource example app it is #object in both the ring server and the test, AND the handler gets called correctly in the test

aside, I’m on Clojure 1.9.0 in my project, and the example is on 1.8.0

that seems to be working ok.

(:a {:a (fn [] identity)})
; => #object[example.handler$eval20719$fn__20720 0x3ddd3f34 "[email protected]"]

@kennethkalmer #object[....] seems to be normal. If the route doesn’t match, maybe it’s something in the routing itself? a missing trailing “/” maybe?

(context "/pizza/" [] I think context path shouldn't usually end in /

I agree, been trying hard to avoid trailing slashes since we already have clients

but yeah, probably the route isn’t matching so doesn’t get called