I just searched many topics of camel, many of them mentioned that Camel provided the rest api support, but I don't know why it provides it ? As it can integrate many frameworks , for example spring, and springmvc/springboot also provide the rest ability.
As a beginner for camel, the first question of mine is just : what's the benifit / adv of apache camel for rest ? why use camel rest route api rather than springboot restcontroller ? At least, you can see that springboot rest controller can provide the restful api with explicit design/implementations, readable annotations and well integrated with spring validation, swagger UI , etc.
Another question from me, if need to use apache camel, can we use spring rest controller for rest api and camel for other parts ? Or it's not suggested to do things in this way ?
Well, Camel is an integration library that can be used in many environments. It can be used standalone, with Spring Framework, in Apache Karaf etc. So this is a first point:
When Camel is used without Spring, it is worth nothing that Spring has excellent REST support.
Camel excels with its more than 200 components. It supports mainly everything (protocols, data formats etc) that is used out there and it abstracts most of the annoying transport level code away from you. You simply use a DSL to build integrations between different types of endpoints.
rest("/orders")
.post()
.to("activemq:queue:myQueue")
This is a 3 line Camel integration that receives REST calls from clients (POST) and sends the received data to a JMS message queue. Here we got the second point:
Even if Spring is available, Camel must provide REST support in the Camel DSL to allow REST integrations with other endpoints
And yes, you can of course use the Spring Framework to build a REST service and then call this REST service from a Camel Route. But what is not possible, is using this Spring REST service as a Consumer of a Camel Route (the 3-line example above).
Burki's response is great. In my opinion, it does worth adding two additional points.
if you like the way Spring lets you implement your service, you can still benefit from both worlds and integrate your #RestController with your Camel Route by using an istance of FluentProducerTemplate.
if you build your service with Camel from the beginning, including the Rest DSL you can take advantage of Camel's error handling implementation (which is very great, imho) from the earliest stages of your application
More often than not, using Camel is not just a matter of having fewer lines of code. Camel brings you the power of a complete lightweight framework, more than 280 components, type and dataformat converters, not to mention EIPs, therefore REST DSL can be considered just as the front door :)
Related
I am trying to build a new application with spring boot microservice framework. I have tried some demo. The existing demo is too simple, doesn't introduce how to call another service from one service. Should still going through http, or should going through RPC? If going RPC, which RPC framework support?
The way of integrating among services depends on numerous factors, like synchronicity/asynchronicity, load that will be generated, etc. The most popular (I guess) way of integration is REST-based one. Because you tagged your question with spring I would recommend using declarative REST client - Feign that is very well described here. You can use message brokers as well, which are also very well abstracted by Spring Cloud Stream - you can read more here. I think that more in depth discussion should be based on your needs.
If another micro-services are exposing the REST API , then you can simple use jersey client
or httpclient to call them.
I have been contemplating on building a test jar for a community of developers in order to expose a preview of a next release of an API (having stubs returning expected response with exact format etc). We do have both REST and SOAP API. I guess it won't be any problem building the REST Service as the net is flooded with example. It was quite surprising there isn't much of concrete example of how to build SOAP service (JAXWS) with spring boot with embedded jetty.
What I expect to achieve is one single jar with both APIs. I am rather comfortable developing a java first services. I have seen a post in stackoverflow but it doesn't clearly outline steps to achieve that. I know it's possible because dropwizard guys have similar project.
I will be grateful if there is any resource with example on how to handle SOAP web services in spring boot.
Thanks you in advance
Spring already supports JAXWS through *JaxWsServiceExporter and SpringBeanAutowiringSupport (in spring-web). The *Exporter approach doesn't quite mesh with the REST stuff because it isn't in the embedded container. You'd end up with an app listening on 2 ports (one for XML and one for JSON). If either of those works then you have a solution. If you don't really care that much about SOAP and just want XML representations, you can use normal content negotiation features (e.g. #ResponseBody or #RestController for everything).
I have my web application written in Spring MVC. It is quite simple app for registering some activities and generating reports after some time. Now I have it done fully in Spring. The only entry point is HTTP webapp request. I'd like to add other entry points to allow user to trigger application via JMS queue, FTP files and SOAP-based web service.
I know I can do this all using Spring own features somehow, but I wonder if it is desirable to involve Apache Camel into all that stuff?
I think about leaving web application as it is (communicating directly with services), only add some Camel magic to spring context and expose several endpoints from Camel and then after messages processing and transformations call existing services.
I think about using Camel to be able to use some asynchronous processing and threads/scalability features. Is it the right way to go?
I will recommend you to use Apache Camel. I have used it for a similar purpose. The solution is an appropriate one from a 'Separation of Concerns' point. Camel implement Enterprise Integration Patters and is a better solution for integrating various protocols and interfaces. Your application should deal with functionality only and as designed should just expose a servlet to get requests and process it.
Handling of interfaces and protocols are well structured in Camel and its easy to maintain and configure in the long run.
Evening all :)
I'm looking to create a Java web application. I envisage that it will use Spring web MVC and JSPs, however I would like to expose certain functionality as REST calls so I can create an android client.
Does spring offer anything to help me in this area? How can I keep the REST code and the web front end code separate yet not have to maintain essentially 2 versions of my application (one for the web, one for REST clients).
Not looking for spoon feeding, just some pointers of where I should start reading.
As others have mentioned, Spring has pretty good in-built REST support now. When combined with annotations, this allows really simple set-up of a RESTful API. Spring can be configured with different view resolvers, which can automatically respond with a different view of the data depending on the Accept header for example. So you could return either JSON or JSP automatically from the same data, see the ContentNegotiatingViewResolver. Your Controller and Model can then be common and implemented once, leaving the work in the View layer.
I've used this approach before to return JSON when the request was via AJAX and a JSP view built with the same data when accessed by a browser.
Jersey is a pretty nifty tool. It integrates well with tools like Spring, Guice, and Jackson to provide you a pretty seamless way to create RESTful resources.
Jersey is pretty simple, works well, and serves as the reference implementation to boot. Plus, it has some nice REST client support, much of which will probably make it into the JAX-RS spec.
In terms of marrying that with Spring MVC, I'd recommend you make sure you model your application so that you have facades (Service classes) that provide all the core functionality you need and then simply reference them as needed in your MVC code or REST code. You shouldn't be duplicating business logic
You can do this using Spring 3.0. Spring 3.0 came out with the ability to specify #PathVariables to pull values out of the URL path (previously this was not easy in Spring MVC).
You would also use #RequestMapping to specify the HTTP method(s) each method in your controller should respond to.
I've also use Spring Security to implement an API key type of functionality. This way you can restrict access to your API in a way that is easy for REST clients to implement. I had to extend org.springframework.web.filter.GenericFilterBean and add a the proper Authentication like this
SecurityContextHolder.getContext().setAuthentication(apiKeyAuth)
There's a new REST API in Spring 3.0 MVC:
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
http://www.springsource.org/download
Apache CXF integrates well with Spring and offers many method for exposing services. From the overview section of the CXF homepage:
CXF helps you build and develop
services using frontend programming
APIs, like JAX-WS and JAX-RS. These
services can speak a variety of
protocols such as SOAP, XML/HTTP,
RESTful HTTP, or CORBA and work over a
variety of transports such as HTTP,
JMS or JBI.
I am totally new to Spring Web Services and so what concept should I start concentrating on and where should I be looking for them and in general what steps would you recommend to get to speed with Spring Webservices Module.
Note: I have an requirement to build Web Service for and consume Web Service from different application and I have never worked with Web Service in the past, I am looking at Spring WS option because both application are developed using Spring Framework, is this a good assumption to look for Spring WS or not ?
Any guidance and suggestion for discussion kind of approach would be highly appreciated.
Thanks.
(...) I am looking at Spring WS option because both application are developed using Spring Framework, is this a good assumption to look for Spring WS or not?
It's not a wrong assumption (bad integration between Spring WS and Spring would be a total irony) but you should not exclude other stacks on the fact your applications are using Spring. JAX-WS stacks (like Apache CFX or JAX-WS RI) provide Spring integration as well.
Personally, I like JAX-WS (that I use for contract-first web services) and, while it's hard to be more specific without more details about your requirements, I simply don't think that Spring WS offers any advantages over JAX-WS and I would probably go for Apache CXF in your case.
Maybe have a look at what others are saying in this previous SO question (please read all answers, the accepted one is not really good in my opinion).
What are your protocol requirements? Do you have to use SOAP, or are you free to use your own XML marshalling over HTTP (e.g. a RESTful approach)?
If you must use SOAP, then see this guide I wrote to Spring WS web services. If you're free to use your own lightweight RESTful web services, then see this example I wrote on RESTful web services.
I wouldn't use Spring WS ONLY because of the reasoning you provide. You need to identify more functional requirments like:
Can you use markup (JSON, XML, etc.)
Should you provide content negotiation
Do you need to provide complex objects (i.e. SOAP as james suggests)
Are you providing a RESTful service
etc.
I've worked with web services a lot in the past few years and there seems to be a few major projects for creating them:
Apache Axis (primarily SOAP)
Apache CXF (primarily SOAP)
Jersey (REST)
Restlet (REST)
There are other offshoots like Spring WS, or even Spring MVC, but you need to evalute which will work best.
Personally I use Jersey a lot, which also provides Spring integration. Jersey also has an awesome HTTP client for consuming services, but don't confuse creating a web service as being akin to consuming a web service. They are separate workflows and you could use separate third-party projects for both (e.g. Apache HTTP Client for consuming, and Jersey for producing).
Spring WS might work best for you, but my advice would be don't use it just because the other applications use it...use whatever works best and fulfills your requirements.