Develop Reference

Apache Camel modifies JSON when CONTENT_TYPE is application/json

I'm building my REST-API with Apache Camel and I use "bindingMode(RestBindingMode.json)" for my restConfiguration with jetty. In one of my Processors I set the "body" of the "out" object with a String that actually is a JSON object. When I set the Exchange.CONTENT_TYPE to "text/plain" the response comes in as expected and can directly be parsed to a JSON object.
{"mockBasicData":"123"}
But when I set the Exchange.CONTENT_TYPE to "application/json" or if I don't set it at all, Camel manipulates the body and escapes it, like it wouldn't already be a JSON object.
{\"mockBasicData\":\"123\"}
Is there a way to avoid that auto-escaping in Camel, as I need the CONTENT_TYPE to be "application/json"?

The typical use of the RestBinding is to specify the marshalling from POJO to json or xml. If I understand correctly what you said, you are converting a json string body to json, right ?
If so, have you tried to set the body of the out object with the JSON Object it-self ?
Please also note the following:
From Camel 2.16.3 onwards the binding from POJO to JSon/JAXB will only
happen if the content-type header includes json or xml. This allows
you to specify a custom content-type if the message body should not
attempt to be marshalled using the binding. This is useful if, for
example, the message body is a custom binary payload.

Adding "bindingMode(RestBindingMode.off)" directly to the route (not to rest()!) solved it for me.

Multiple content-types for request in webservice

I have one webservice which can take multiple content-types in request
text/plain
application/json
Now, client can send any of them either json or text.
I have two options available on server
I can create separate apis for different content types
I can parse request data and check if its json or text?
What is better approach here?Is there a design pattern suited for this need?
Note: Management prefer to have one api which can support multiple content-types.

The client must include a Content-Type header indicating the format of the entity they are sending to the server. If the server does not support the format which a client has sent, the expected response is 415 Unsupported Media Type.

I would go with option 1 and have the common logic placed in a seperate method. That way you let the API check and parse the input data for you.

In http you use the "accept"- header to define what type you expect the response to be. The server delivers the content as defined in accept header, the default if it's not set or 406 - "Not acceptable" if the type is not supported
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

One way would be to use #Path annotations more thoroughly-
The #javax.ws.rs.Path annotation must exist on either the class and/or a resource method. If it exists on both the class and method, the relative path to the resource method is a concatenation of the class and method.
See this link https://docs.jboss.org/resteasy/docs/1.1.GA/userguide/html/Using__Path_and__GET___POST__etc..html

What is the appropriate routingkey value for headers exchanges in RabbitMQ?

The Channel class (Java Client) provide three methods to publish a message, all of them with the routingkey parameter. The headers exchange does not need the routingkey.
If i pass a null value for the routingkey, the following exception is returned: "java.lang.IllegalStateException: Invalid configuration: 'routingKey' must be non-null."
However, if i pass an empty string it works. So the question is: Is it correct to use an empty string?

Yes, it is correct to use empty string. The routing key is not used by headers exchanges as defined in AMQP protocol specification.
Most likely exception is thrown because driver doesn't know anything about setup and it's much safer to handle all errors, including potential errors, on client side.

How does Restlet client handle media type of request?

I've got several newbie questions about how Restlet client handles media type header:
What will Restlet client put in 'content-type' header if I pass in an entity of type a) a POJO or b) an InputStream instance? And what the 'accept' header will be?
If I want to transfer a POJO in JSON format in HTTP body, do I need to serialize the POJO and pass it in as a JSON string or can I just pass in the POJO and Restlet will do the rest? If it's the former case, do I need to specify the 'content-type' header and how?
Thanks a lot!

If you rely on the ClientResource class, you can add a MediaType parameter to your put call, such as
put(myPojo, MediaType.APPLICATION_JSON);
UPDATE
Actually, the extra media type parameter defines the accepted result type expected from the remote resource, but doesn't apply to the sent entity.
The control on the media type of the entity/POJO sent is based on the ConverterService default settings, which depends on the extensions available on your classpath and their respective order.
You can have full control by directly invoking the
ClientResource cr = new ClientResource("http://targetDomain/path");
cr.put(cr.toRepresentation(myPojo, new Variant(MediaType.APPLICATION_JSON));
You also need to add the org.restlet.ext.jackson extension on your classpath and its dependencies. The XStream extension is another option.

Pass object as arument in RESTful web service

I am creating a simple RESTful web service with simple types successfully. Now I want to pass an object as argument for web service and get the object as response. My scenario is, Parse the XML message as object by using Jaxb and send the object as request for web service. After that in server side it process the requested object and generates the response xml file and send back it as object.
In URL path i give
"http://localhost:8080/SampleWS/rest/checkXML/username=visolve&password=visolve"
for simple type. But in object I don't know how to give the object reference in URL. Please help me how to solve my problem..
Regards
Bathakarai

Just define a very good-looking domain object. JAXB and JAX-RS will do the rest.
JAXB.
#XmlRootElement
class Regards {
#XmlElement
private long sincerely;
}
JAX-RS.
#Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
#POST
#Path("/sincerely")
#Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Response sincerely(final Regards regards) {
regards.setSincerely(System.currentTimeMillis());
return Response.ok(regards).build();
}

Though you could certainly include the entire XML content in your URL, I would probably shy away from it.
Think of it this way: if you encode the XML in the URL you're potentially adding more work on both ends. Now the server and client will both need to know how to build the URL properly, and check to make sure everything lines up correctly. What if, in the future, you need to offer a JSON or YAML view of the same content? Now your URL might need to include the content-type as well. What about character-encoding?
All this to say, HTTP provides a terrific transport mechanism which already addresses these concerns. Include the XML as the entity body of the HTTP message, and use the HTTP header to identify what content-type you're sending, character-encoding, etc. This will work both ways (the server and client both can send the XML back/forth), and makes better use of HTTP.
Here's a related link which might help with some of the details. And another.
On a side note, please, please, please tell me you don't plan on sending user-credentials in plain text across an unencrypted link.