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
(http://camel.apache.org/rest.html and
http://camel.apache.org/rest-dsl.html) 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 <[email protected]>
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
<[email protected]> 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("{ ${header.name} }"));
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
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition: http://www.manning.com/ibsen2
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
