`:as-response` fn fires when representation params are not set in the context and returning the resource as-is fails.

[Chris Hapgood]

I see much discussion regarding content negotiation for errors and I look forward to that capability.  Liberator is awesome and this coming feature will simply add to the power of this great tool.

In the meantime, I am struggling with using `as-response` to set custom headers on 2XX responses *and* handling errors like not `authorized?`.  The `authorized?` decision point is executed before content negotiation, so my custom as-response can't simply call `liberator.representation/as-response`.  But unfortunately, neither can I simple return the resource (the first parameter to the as-response function) directly. It results in the error ": No method in multimethod 'render-map-generic' for dispatch value: null".

Is it correct that if I implement `as-response` for my success cases, I also need to re-implement response generation for errors in that same function?

[Chris Hapgood]

Elaborating on my own musings above, it is unfortunate that `as-response` fires for error situations as well as success conditions.  There are fundamentally different requirements for the two cases if one is happy with the default Liberator error responses (error: simple text/plain message, success: crazy content-type specific requirements and custom headers). 

[Philipp Meier]

Am Mittwoch, 21. Juni 2017 17:15:07 UTC+2 schrieb Chris Hapgood:

Elaborating on my own musings above, it is unfortunate that `as-response` fires for error situations as well as success conditions.  There are fundamentally different requirements for the two cases if one is happy with the default Liberator error responses (error: simple text/plain message, success: crazy content-type specific requirements and custom headers). 

I'm thinking about making content-negotiation for the actual resource independent of content-negotiation in case of error. Some discussion happened in #94 but I'm not yet come to a conclusion.

-billy.