You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, thanks for this amazing tool. It's what I've been looking for a long time.
I'm consuming an api that has an operation with response.content set to "/", whereas it actually produces application/json.
I'm using clj-http, and for this case, martian uses its { :as :auto } option. The server responds with content-type: application/json, so clj/http auto-coerces the result into a map, whereas the martian coercion interceptor still expects a string, and then fails when it calls cheshire to decode. I wonder what the best way to mitigate this would be (apart from fixing the api spec).
The text was updated successfully, but these errors were encountered:
I would say that it could simply check if the body is a string, and just pass it straight through if not. This should be a simple change (in fact I thought it already did this). I'll try to do it soon, or else PRs always welcome.
Yes that would work, but not sure if it's the best solution. Maybe its not needed if we get it right earlier.
As a workaround, I just remove :as :auto in another interceptor that I insert after interceptors/coerce-response.
Maybe one could allow a customizable auto-encoder (e.g. via a special key in the encoders map)
I'm also not sure if there's really a valid use case to ever pass :as :auto, I would maybe consider removing it.
Then also.. you dont want to break existing clients, so maybe customizable auto-encoder is the way to go.
Hi, thanks for this amazing tool. It's what I've been looking for a long time.
I'm consuming an api that has an operation with response.content set to "/", whereas it actually produces application/json.
I'm using clj-http, and for this case, martian uses its { :as :auto } option. The server responds with content-type: application/json, so clj/http auto-coerces the result into a map, whereas the martian coercion interceptor still expects a string, and then fails when it calls cheshire to decode. I wonder what the best way to mitigate this would be (apart from fixing the api spec).
The text was updated successfully, but these errors were encountered: