Rest DSL Media Type

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Rest DSL Media Type

Gregor Zurowski-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Rest DSL Media Type

Claus Ibsen-2
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Rest DSL Media Type

Gregor Zurowski-2
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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Rest DSL Media Type

Sergey Beryozkin
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 <[hidden email]> 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 <[hidden email]> 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/
Reply | Threaded
Open this post in threaded view
|

Re: Rest DSL Media Type

Sergey Beryozkin
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 <[hidden email]>
>> 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
>>> <[hidden email]> 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/
Reply | Threaded
Open this post in threaded view
|

Rest DSL: multiple produces values

Sergey Beryozkin
Hi

Is it possible to have a single REST DSL route producing multiple
formats, example, either JSON or XML ?
I thought it was possible but not sure now.
Suppose I have a client with

Accept: application/json, application/xml
(with .q factor if needed)

and I thought if I have .produces(application/json, application/xml) in
RESTDSL then it will work. But API only allows to set a single binding
mode for a given route, ex either XML or JSON. I can see I can bypass it
for CXF by not setting a binding mode at all and simply expecting users
to rely on JAX-RS providers. But, Claus, perhaps you might want to
review it and consider adding multiple binding modes - sorry if it is
actually possible, do not see for now.

The other concern I have now is the selection criteria between multiple
matching routes, example, /a/{b}/c and /a/{b}/{c}, both matching GET
/a/b/c. Possibly not an issue for trivial APIs but otherwise there has
to be a selection criteria in place. Perhaps REST DSL consumers may
optionally advise via some future API improvements which route has to be
chosen when multiple candidates are available ?

Thanks, Sergey
Reply | Threaded
Open this post in threaded view
|

Re: Rest DSL Media Type

Claus Ibsen-2
In reply to this post by Claus Ibsen-2
I logged a ticket
https://issues.apache.org/jira/browse/CAMEL-8528

And as Sergey also says we can with all the information from the
rest-dsl uses that as fallback to set the CT header, so Gregors
example also would work. This makes rest-dsl simpler to use, and for
use-cases where you just do a get -> to, and setup the
consumes/producers information.

On Thu, Sep 3, 2015 at 5:19 PM, Claus Ibsen <[hidden email]> 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 <[hidden email]> 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



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition:
https://www.manning.com/books/camel-in-action-second-edition