It depends on what you're exposing the endpoint for. If the REST endpoint is a gateway to a business process / service orchestration / aggregation / scatter-gather / etc. (replace with any kind of EIP or combination of EIPs), speaking to 10+ systems over different protocols (SOAP, plain HTTP, JMS, TCP, FTP, File, Mail, AWS SQS, etc.) or bridging different technologies (MongoDB, JDBC, Salesforce, Facebook, Twitter, etc.), then it clearly makes sense to use Camel. It is integration work and that's what Camel is built for.
If your REST endpoint is simply a micro-service with business logic, you may as well use plain JAX-RS as you propose and inject a ProducerTemplate if you want to leverage Camel in an ad-hoc manner. Regards, *Raúl Kripalani* Apache Camel PMC Member & Committer | Enterprise Architect, Open Source Integration specialist http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk On Mon, Mar 31, 2014 at 4:24 PM, akcameluser <ayache.khet...@gmail.com>wrote: > Hi > > Just a brief comment. I wonder why people would expose a REST service > through Camel Route? camel-http (jetty) would do the Job of exposing an > HTTP > endpoint. You will have to do the serialization and deserialization of JSON > yourself, but much simpler way of exposing the endpoint. If you are looking > for REST service with an elaborate REST API then go for another technology > like Javax-rs(jersey) or Spring REST. Anyway this is my opinion and I might > be wrong. > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Issues-with-cxfrs-using-json-tp5749474p5749568.html > Sent from the Camel - Users mailing list archive at Nabble.com. >