In the future I may use the new REST DSL if I find an appropriate place for it. It seems rather straightforward. I'd just have to make sure I was working on an exclusive REST API and was certain that being tied to HTTP was going to be OK.
I was a little surprised to find it embedded in the RouteBuilder code. I'd sort of assumed something like that would have been in its own class or even separate jar/bundle. On Thu, Feb 11, 2016 at 10:29 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > On 11/02/16 16:23, Brad Johnson wrote: > >> If you're using the CXFRs with annotated interfaces there isn't a need to >> be aware of the verb that I'm aware of since the method invoked on the >> interface itself will actually determine the route to invoke when using >> the >> recipient list. The only qualifier there is that the Java interface >> method >> names will have to be unique for each resource. >> >> I've not used the REST DSL so can't comment on it. But the routing via >> CXFRS is simple with the recipientList mechanics. That's especially true >> now that null/no-op implementations are no longer required. >> > > Great, I guess this is what I was vaguely referring to, that some > component can help streamline the route processing when working with CXFRS > while you actually know how to do it :-) > > Cheers, Sergey > > > The interface >> with annotations works. For me, where I have endpoints with both SOAP and >> REST requirements it is nice to be able to do it that way. >> >> On Thu, Feb 11, 2016 at 9:20 AM, Sergey Beryozkin <sberyoz...@gmail.com> >> wrote: >> >> The difference is declarative vs code-centric, in CXFRS we still have HTTP >>> methods, but the custom processor needs to do the actual routing based on >>> the matched verb. >>> >>> This verb is actually stored on the Camel exchange/message so I'd not be >>> surprised if it were possible to do it declaratively with some of Camel >>> components which check this verb which sits after from:cxfrs. >>> >>> The other difference is that REST DSL is meant to be HTTP-aware component >>> neutral, as I mentioned CXFRS will support REST DSL eventually... >>> >>> Sergey >>> >>> >>> On 11/02/16 15:13, camel_case wrote: >>> >>> Thanks for the correct processor link. >>>> I'm summarizing main difference between rest dsl routes and cxfrs routes >>>> rest dsl can include the method .get .post .put .delete baked into the >>>> route >>>> This is an advantage if you want a different route for each http method, >>>> whereas the cxfrs has paths, params, consumer producer return types >>>> configured in resource file (interface or class) >>>> >>>> Unclear about deciding factors favoring one over the other aside from >>>> these >>>> obvious structural differences. >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> >>>> http://camel.465427.n5.nabble.com/Multiple-consumers-for-the-same-endpoint-is-not-allowed-cxfrs-vs-rest-dsl-tp5777492p5777600.html >>>> Sent from the Camel - Users mailing list archive at Nabble.com. >>>> >>>> >>>> >>> >> > >
