camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Rest DSL Media Type
Date Thu, 03 Sep 2015 16:46:48 GMT
I'm sorry, this was somewhat off-topic as failing non-matching clients 
is a different issue to setting a response Content-Type, however, FYI, 
once the intersection of 'produces' and Accept is done the response CT 
is already known in most cases - this is something a given REST DSL 
consumer can do.
Using produces as a fallback is reasonable too on its own.
IMHO it should be noted that apart from using produces/consumes for the 
documentation it is up to a given consumer to treat them for the media 
type intersection(IMHO it should be a requirement rather than an option 
because such the intersection is what generally expected from HTTP 
consumers - but I've no problems with doing it at cxfrs level only)

Thanks, Sergey
On 03/09/15 17:38, Sergey Beryozkin wrote:
> The problem with expecting a binding mode provider set a response
> content type is that the client with Accept not matching this 'produces'
> still gets a result it does not expect - I reported this issue separately.
> Example, if the client sets Accept: application/xml and hits a route
> that produces JSON then it should definitely get the error before the
> binding mode (JSON) etc gets a chance to process a response, in fact the
> route should not even run IMHO.
> The same with consumes - if one posts XML to a route expecting JSON then
> it should be a proper HTTP error as opposed to a JSON reader failing to
> read something it should not.
> I honestly thought produces/consumes properties were supposed to be more
> effective.
> I think a given REST DSL integrator is allowed to use them more
> pro-actively ? The original meaning was for the documentation which is
> fine, but it is part of REST DSL 'API' hence a given integrator is fine
> with enforcing produces/consumes, otherwise, as far as CXF is concerned,
> it would be a real problem...
> Thanks, Sergey
> On 03/09/15 17:25, Gregor Zurowski wrote:
>> Hi Claus,
>> Thanks for your response. I was not aware that produces/consumes was
>> for documentation purposes only. At least, the documentation
>> ( and
>> does not clearly state this. I
>> will add a note on the Rest DSL wiki page.
>> I like the idea of letting Camel use "produces" as a fallback, as it
>> will simplify REST routes.  Should I log a ticket for this?
>> Thanks,
>> Gregor
>> On Thu, Sep 3, 2015 at 5:19 PM, Claus Ibsen <>
>> wrote:
>>> Hi
>>> That was designed for documentation purpose only (and as a hint to
>>> Camel whether its json or xml data), so what you define in
>>> produces/consumers/description etc is for documentation, and the
>>> swagger-api etc.
>>> I assume when you have binding mode enabled then the library that does
>>> the binding sets the content-type header. And thus why you see the
>>> value.
>>> Though we could consider letting Camel use producers as a fallback if
>>> it hasn't been set, even when you have binding mode turned off?
>>> On Fri, Aug 21, 2015 at 10:55 AM, Gregor Zurowski
>>> <> wrote:
>>>> Hi everyone:
>>>> When I set up the following simple route with Camel 2.15.2 and Rest
>>>> DSL, the response will not contain the media type as specified by the
>>>> 'produces' verb:
>>>> rest("/hello")
>>>>     .produces("application/json")
>>>>     .get("/{name}").to("direct:hello");
>>>> from("direct:hello").transform(simple("{ ${} }"));
>>>> The correct media type is returned when an object is returned by the
>>>> route and binding mode is set to JSON. If a string is returned as
>>>> above, and binding is disabled, no media type is set. I am wondering
>>>> if this is intentional or whether I am missing something?
>>>> Thanks in advance,
>>>> Gregor
>>> --
>>> Claus Ibsen
>>> -----------------
>>> @davsclaus
>>> Camel in Action 2nd edition:

Sergey Beryozkin

Talend Community Coders

View raw message