In one of our projects we are using the spring mvc. The spring mvc has inherent support for REST web services. I am looking forward to some insight/suggestions on how does Springs mvc's REST support fare when compared with the other popular framework like RESTEasy, RESTlet,JAX-RS etc.
The first big differentiator is that Restlet and RESTEasy both provide implementations of JAX-RS. You can write JAX-RS code that either of those frameworks could run and not have to change anything. Spring MVC is a separate API that doesn't implement JAX-RS. It does provide most of the same functionality from what I've seen. Of course, Restlet also provides its own non-JAX-RS based API which is nice too.
I found this seemingly thorough comparison of Spring MVC and JAX-RS at InfoQ that might interest you. I would say, if you are already using Spring MVC and it meets your needs in the REST department, stick with it until you find a need to look for something else.
Related
We are planning to make a new application with spring 4.0.6 version. We use controller that can return "XML" or "JSON".
In the previous project we have successfully implemented Jersey with Spring for REST support using JAX-RS API, but after reading a few articles and suggestions from seniors they said spring is providing pretty good REST support.
Some of the points that really confused me if I use Spring REST support without using JAX-RS and Jersey are:
How marshaling and unmarshaling done in Spring MVC ?
Is it necessary for marshaling or unmarshaling need to use jax-rs.
If marshaling and unmarshaling are automatically handled by spring then how does it know about xmlRootElements.
I am still confused if Spring proving very good support of REST then why do people still go with Jersey for REST?
Really looking to know more in details.
If I said anything wrong please ignore it.
Explanation with example is really helpful.
I'd say both Jersey and Spring MVC are great - each project has its own style and strengths. Anyway, Stack Overflow is not the right place for asking subjective comparisons (your question would be closed quite quickly). If you're already using Spring for everything else and are not required to use JAX-RS, then Spring MVC makes total sense.
Regarding features like (un)marshalling, JAX-RS is just a spec after all - other libraries can offer similar features without implementing the same API.
Instead of MessageBodyReaders/Writers, Spring MVC is using HttpMessageConverters to handle (un)marshalling REST resources. Spring MVC handles content negotiation and chooses the best available converter for the job (you can annotate methods to hint at what media type they produce/consume).
No, it's not necessary to use JAX-RS to (un)marshall resources. In fact, JAX-RS implementations and Spring MVC use third party serialization libraries to do the job; so it's not tied to a particular standard.
In its 4.0.6 version, Spring supports many HttpMessageConverters, with Jackson for JSON, JAXB for XML and many others. Spring 4.1.0 added more HttpMessageConverters:
Jackson is now available for both JSON and XML
Google Protobuf
Gson for JSON, as an alternative to Jackson
To answer your last point, #XmlRootElement is a JAXB annotation and is not part of JAX-RS. Spring supports JAXB.
For a more complete example with REST in Spring, check out this getting started guide (you'll get a complete example running in 10-15 minutes).
Again the last part of your question is quite subjective - there are many popular solutions for building REST services in the JVM, not just Jersey and Spring (Dropwizard, Play! Framework, etc).
AFAIK Spring REST support is based on Spring MVC and its not JAX-RS implementation while Jersey has implemented JAX-RS specification.
Those having Spring (Core, AOP or MVC) in their project chooses Spring ReST support over JAX-RS implementor.
I recommend Jersey as its mature, implements JAX-RS and is easy to use.
I have a spring based project that need Rest API support for developing Rest client. This is a very high load application and I need a Rest implementation that with good performance. I've found in many article like one here that CXF is a great performance wise but initial effort in configuration and POC seems to be to much. Haven't found a lot of documentation regarding the API usage.
Can any one suggest weather I should use spring or CXF.
You should also try Restlet and Jersey. By doing some demo projects with each one of them, you can find out which one best suit you.
im using spring MVC and webflow to create a game server and serve some web pages to the users. Thing is, the javascript game will also make multiple ajax calls to restful services on the same server for some game logic. While the web page serving performance is not critical, the restful service calls need to be as efficient as possible (efficient as in response time).
For performance of the services, would it be better to use pure JAX-RS (jersey) web service calls without the spring ws overhead (since i understand the spring layer could affect performances negatively) or would it be the same if i used the spring webservices framework instead and maintain integration with the rest of the spring family?
thanks!
There aren't many clear benchmarks out there, but take a look here:
http://www.techempower.com/benchmarks/
It clearly shows the overhead of using Spring. Compared to Servlets that serve JSON manually Spring is "slower". Personally, I don't think that Spring cuts development time, unless you are very much familiar with it. Creating a simple servlet that will act as a REST API is very simple. Take a look at the servlet code from the benchmark:
Servlet benchmark
I don't think Spring per se will affect performance negatively. Where did you hear that?
Spring web services are "contract first" SOAP services. If you're saying that you don't want to pay the overhead of SOAP, XML, marshalling and unmarshalling, then you have a valid point. That's true whether you use Spring to implement the services or not.
REST is HTTP, so it's a natural for AJAX calls.
I believe Spring 3.0 supports REST, so it's not a "Spring or not Spring" choice:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/new-in-3.html#d0e1188
I have a question regarding RESTful client implementation.
At this moment I have developed the server using RESTeasy and EJB. Method return JSON in much case. And now we are starting backend development(WEB). And can't select a framework for this, that supports authorization, authentication...
Could you suggest a pattern, framework, approach etc..
If you looking for a Java web framework that fits your existing technology (EJB) you should take a look at JSF and WebBeans (note though that JSF does not expose RESTful URLs for its actions/controllers).
However since you also mentioned REST I guess you just want a backend framework for your services that can handle user security and auth. In this case you should take a look at spring (in particular spring-security and spring-web). Most JAX-RS implementations have good support for spring, although I should mention that spring itself has a splendid REST framework that of cause works very well with their other offerings.
If on the other hand you want a framework that can handle security in the context of a EJB application that exposes a RESTful service, then you are in a tough spot. RESTful applications are meant to keep most of the state at the client, in contrast to most EJB apps that frequently uses state-full session beans. You can integrate JAX-RS with stateless or singleton EJBs and then either use spring-security to handle the security/auth or use the <security-constraint> in the web.xml as described here
Is there any reason to use Spring MVC (or other similar frameworks) as a server for GWT RPC? As far as I can tell, 99.9% features of Spring will not be used. Yet, lots of people are looking for best ways to use them together.
Could someone please explain, what are the benefits of using MVC frameworks (on server) with GWT, when all you need on server side is business logic?
I don't see any generally good point in using Spring MVC or another enterprise Java MVC library (like Struts) together with a layer which - as you said - offers only business logic (and therefore can be kept as small and clean as possible).
But Spring itself is way more than just a web (MVC) framework layer and using the dependency injection or AOP features or the ORM API or the Scripting language Groovy (which works fine with Spring) can be a huge benefit for any application.
Spring is much more than just MVC.
Even when you do your UI with GWT, you still need some kind of backend logic.
Things like databases, transactions, security, additional services integrations (emails? SOAP?) and so on.
For this Spring or any other Java server side technology can be a good solution.
As daff said, Spring brings DI + AOP + transactions + many things...
It is useful to have those stuffs managed on your server side with Spring.
Furthermore, the library gwtrpc-spring offers a very convenient way to declare POJOS as rpc services, with the #Service annotation. It avoids declaration of each rpc servlets in the web.xml, as the scan for classes with #Service is automatic.
GWT is just a toolkit, not a framework. If Spring can ease your dev, just use it.
I tend to go for GWT + GIN on the client side and Guice on the server side.
But Spring could just as wel be used for persistance, transactions and organising your business logic on the server side.