handle-malformed raises exception when returning a map

[JuneKelly]

When I try to return a map (json) from handle-malformed, the server crashes with the following exception:

>> java.lang.IllegalArgumentException:
>> No method in multimethod 'render-map-generic' for dispatch value: null
>> MultiFn.java:160 clojure.lang.MultiFn.getFn
>> MultiFn.java:231 clojure.lang.MultiFn.invoke
>> representation.clj:210 liberator.representation/fn
>> representation.clj:23 liberator.representation/fn[fn]
>>                        core.clj:176 liberator.core/run-handler
>> core.clj:485 liberator.core/handle-malformed
>> core.clj:93 liberator.core/decide
...

The following code is an example:

(defresource something
...
  :malformed?
  (fn [context]
    (let [params (get-in context [:request :params])]
      (empty? (params :imageData))))

  :handle-malformed
  (fn [_]
    {:error "Error: imageData required"})
...

If the handle-malformed function is replaced with a string, the code works and a plain text string is returned to the client, however this is not a workable solution as the api needs to consistently deal with json rather than sometimes returning plain text. :)

Seeing as other handle-xyz branches can return map data, I presume that handle-malformed should be able to do the same?

Tested on Ubuntu 13.10 , liberator 0.10.0 .

[ordnungswidrig]

This is a nasty gap in liberator. The context will not have a negotiated media type available until the decision point media-type-available? is executed. But there is a simple workaround: assoc the desired media-type in the context:

(defresource someting
:malformed? (fn[ctx](when-not %28get-in ctx [:request :params :imageDate]%29 {:representation {:media-type "application/json"}}))

[JuneKelly]

Thanks for that.

However, is there a way to do this assoc while still returning a boolean from :malformed? ?
I've tried the code you gave as an example and it always evaluates :malformed? to true, (i guess because a map is a truthy value). It's possible that I'm just using the example wrong though.

EDIT: I figured it out, If I return a vector, the first entry being the boolean result of the decision and the second entry being the :representation map, then it all appears to work. My code as it stands now:

  :malformed?
  (fn [context]
    (let [params (get-in context [:request :params])]
      [(empty? (params :imageData))
       {:representation {:media-type "application/json"}}]))

  :handle-malformed
  (fn [_]
    {:error "imageData required"})

That's a pretty neat way of handling things, but not obvious until I tried it by chance. Thanks for the help :)

[graue]

I just hit this, and it applies to handle-forbidden as well. Trying to make my API behave nicely and return JSON error responses. Glad to hear a fix is in the works.

[conan]

I'm having to include the :representation key in all my :malformed? decisions too, it'd be nice to have a cleaner way of expressing this.

[lmatoso]

Any news on this?

[ricardojmendez]

I figured it out, If I return a vector, the first entry being the boolean result of the decision and the second entry being the :representation map, then it all appears to work.

Is this supposed to be the expected behavior? Or should we expect this to be fixed in the near future?

[graue]

@ricardojmendez: It's always legal to provide a return value of this form, so you don't have to worry about this workaround being broken by a fix, if that's what you're asking. (The fix would be to negotiate an appropriate content-type for you in this case, making it optional to specify one, but still allowed.)

[ricardojmendez]

Thanks @graue, I was indeed wondering if a future release would end up breaking this workaround. I can live with returning the content-type.

[ghedamat]

@ShaneKilkelly thanks for the workaround!

[mveytsman]

I found a slightly more "elegant" fix.

Since I know my API will always return JSON, I can add the media type to :service-available? which is the first node on the decision graph, i.e.

(def base-resource 
  {:service-available? {:representation {:media-type "application/json"}
   :handle-malformed {:error "malformed"}
   :available-media-types ["application/json"]}

(defresource myresource
  baseresource
  :handle-ok {:status "OK"})

I'm not shooting myself in the face by doing this, right?

[xpe]

@mveytsman Work-arounds are, by definition, sub-optimal. :) Some thoughts:

• It seems to me that whatever you do in :service-available? should only semantically impact the part of your API directly having to do with service availability. Merging something into the context is quite non-intuitive. 503 Service Unavailable means (per Wikipedia): "The server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state."
• I would have less of a concern if you attached the :representation to the initial context if you could do so in a clear fashion, such as with an initial value. I don't know if that is possible (yet).
• But relying on the knowledge that :service-available comes first and then merging :representation into the context seems brittle, coupled, and semantically confusing.

So, yes, I think you are shooting yourself in the foot, as well as anyone who reads the code. But I can't blame you for exploring work-arounds.